Quel est le moyen le plus simple de valider et de pousser un seul fichier tout en laissant d’autres modifications?

Question

Je suis relativement nouveau dans Mercurial et mon équipe l’essaie actuellement en remplacement de Subversion.

Comment puis-je valider et envoyer un seul fichier vers un autre référentiel tout en laissant les autres modifications de mon répertoire de travail non validées (ou du moins non transférées vers l'autre référentiel)?

Cela se produit pour nous avec les migrations de bases de données. Nous voulons affecter la migration au contrôle de source afin qu'un administrateur de base de données puisse la visualiser et la modifier pendant que nous travaillons sur les modifications de code nécessaires à la migration de la base de données. Les changements ne sont pas encore prêts, nous ne souhaitons donc pas les rejeter tous.

Dans Subversion, je ferais simplement:

svn add my_migration.sql  
# commit only the migration, but not the other files I'm working on
svn commit -m "migration notes" my_mygration.sql

et continuez à travailler localement.

Cela ne fonctionne pas avec mercurial car lorsque je le dépose dans un autre référentiel, si des modifications y sont apportées, je souhaite les supprimer, les fusionner et les valider. qui fusionnent dans le référentiel. Les validations après une fusion ne vous permettent pas d’omettre des fichiers, vous êtes donc obligé de tout valider dans votre référentiel local.

La chose la plus simple que je puisse comprendre est de valider le fichier dans mon référentiel local, de cloner mon référentiel local, d'extraire les nouvelles modifications du référentiel actuel, de les fusionner et de les valider, puis de les transférer vers l'extérieur.

hg add my_migration.sql 
hg commit -m "migration notes" my_migration.sql 
cd ..
hg clone project project-clone
cd project-clone
hg fetch http://hg/project
hg push  http://hg/project

Cela fonctionne, mais il me semble qu'il me manque quelque chose de plus facile, un moyen de dire à Mercurial d'ignorer les fichiers déjà présents dans mon répertoire de travail. Il vous suffit de faire la fusion et d'envoyer les fichiers. Je soupçonne que les files d’attente de Mercurial peuvent le faire, mais je ne m’en suis pas encore complètement à mok.

Answer 1

Il existe une fonctionnalité Mercurial qui implémente les commandes shelve et unshelve, qui vous offre un moyen interactif de spécifier les modifications à stocker jusqu'à une date ultérieure: Schéma .

Vous pouvez ensuite hg stocker et hg unshelve pour stocker temporairement les modifications. Il vous permet de travailler sur le "patch hunk". niveau pour choisir et choisir les articles à ranger. Il ne semble pas que les fichiers listés soient ajoutés, mais uniquement les fichiers déjà dans le référentiel avec modifications.

Il est inclus avec Mercurial en tant qu '"extension". ce qui signifie simplement que vous devez l'activer dans votre fichier de configuration hg.

Notes pour les très anciennes versions de Mercurial (avant l’inclusion de shelve - ce n’est plus nécessaire):

Je n'ai pas vu de bonnes instructions d'installation avec Google, alors voici les éléments combinés que j'avais l'habitude de faire fonctionner:

Obtenez-le avec:

hg clone http://freehg.org/u/tksoh/hgshelve/ hgshelve

Le seul fichier (actuellement) du projet est le fichier hgshelve.py.

Modifiez votre ~ / .hgrc pour ajouter l’extension shelve, en indiquant l’emplacement où vous avez cloné le référentiel:

[extensions] 
hgshelve=/Users/ted/Documents/workspace/hgshelve/hgshelve.py

Answer 2

Cela fait presque 2 ans que j'ai posé cette question à l'origine. Je le ferais différemment maintenant (comme je l'ai mentionné dans un commentaire au-dessus de la question ci-dessus). Ce que je ferais maintenant serait de valider à la place mes modifications dans le fichier de mon référentiel local (vous pouvez utiliser l’extension hg record pour ne valider que les parties d’un fichier):

hg commit -m "commit message" filename

Ensuite, sortez.

hg push

Si un conflit survient parce que d'autres modifications ont été apportées au référentiel que je dois fusionner en premier, je mettrais à jour la révision parente (vue avec "hg parents -r." si vous ne savez pas quoi c'est), commets mes autres modifications là-bas, donc j'ai 2 têtes. Revenez ensuite à la validation de fichier unique d'origine et extrayez / fusionnez les modifications dans cette version. Puis repoussez les modifications avec

hg push --rev .

Pour extraire uniquement le fichier unique et la fusion de cette révision. Ensuite, vous pouvez fusionner les deux têtes que vous avez localement.

Cette méthode supprime les problèmes de mq et le potentiel de mecs rejetés tout en assurant le suivi du contrôle de source. Vous pouvez également " hg strip " révisions hors si vous décidez plus tard que vous ne les voulez pas.

Answer 3

tl; dr: Mon explication initiale a l'air compliquée, mais j'espère qu'elle explique pleinement comment utiliser une file d'attente de correctifs. Voici la version courte:

$ hg qnew -m "migration notes" -f migration my_migration.sql
$ hg qnew -f working-code
# make some changes to your code
$ hg qrefresh # update the patch with the changes you just made
$ hg qfinish -a # turn all the applied patches into normal hg commits

Les files d’attente Mercurial simplifient ce type de travail et rendent plus complexe la manipulation des jeux de modifications. Cela vaut la peine d'apprendre.

Dans cette situation, vous voudrez probablement tout d'abord enregistrer ce qui se trouve dans votre répertoire actuel avant de déposer les modifications:

# create a patch called migration containing your migration
$ hg qnew -m "migration notes" -f migration.patch my_migration.sql
$ hg qseries -v # the current state of the patch queue, A means applied
0 A migration.patch
$ hg qnew -f working-code.patch # put the rest of the code in a patch
$ hg qseries -v
0 A migration.patch
1 A working-code.patch

Faisons maintenant un travail supplémentaire sur le code de travail. Je vais continuer à faire qseries juste pour être explicite, mais une fois que vous aurez créé un modèle mental de files de patchs, vous n'aurez plus à regarder la liste.

$ hg qtop # show the patch we're currently editing
working-code.patch
$ ...hack, hack, hack...
$ hg diff # show the changes that have not been incorporated into the patch
blah, blah
$ hg qrefresh # update the patch with the changes you just made
$ hg qdiff # show the top patch's diff

Comme tout votre travail est maintenant enregistré dans la file d'attente des correctifs, vous pouvez désappliquer ces modifications et les restaurer après les avoir importées. Normalement, pour désappliquer tous les correctifs, faites simplement hg qpop -a . Juste pour montrer l'effet sur la file d'attente des correctifs, je les supprimerai un à la fois.

$ hg qpop # unapply the top patch, U means unapplied
$ hg qseries -v
0 A migration.patch
1 U working-code.patch
$ hg qtop
migration.patch
$ hg qpop
$ hg qseries -v
0 U migration.patch
1 U working-code.patch

À ce stade, c’est comme s’il n’y avait aucune modification dans votre répertoire. Faites le hg fetch . Vous pouvez maintenant appliquer vos modifications à la file d'attente des correctifs et les fusionner en cas de conflit. Ceci est conceptuellement similaire à la rebase de git.

$ hg qpush # put the first patch back on
$ hg qseries -v
0 A migration.patch
1 U working-code.patch
$ hg qfinish -a # turn all the applied patches into normal hg commits
$ hg qseries -v
0 U working-code.patch
$ hg out
migration.patch commit info... blah, blah
$ hg push # push out your changes

À ce stade, vous avez repoussé la migration tout en conservant vos autres modifications locales. Vos autres modifications sont dans un patch dans la file d'attente. Je réalise l'essentiel de mon développement personnel en utilisant une file d'attente de correctifs pour m'aider à mieux structurer mes modifications. Si vous souhaitez vous débarrasser de la file d'attente des correctifs et revenir à un style normal, vous devrez exporter vos modifications et les importer à nouveau dans " normal " mercurial.

$ hg qpush
$ hg qseries -v
0 A working-code.patch
$ hg export qtip > temp.diff
$ rm -r .hg/patches # get rid of mq from the repository entirely
$ hg import --no-commit temp.diff # apply the changes to the working directory
$ rm temp.diff

Je suis extrêmement dépendant des files de correctifs pour le développement et mq est l’une des plus belles implémentations du marché. La possibilité d’apporter plusieurs modifications simultanément améliore réellement la concentration et la propreté de vos commits. Il faut un certain temps pour s'y habituer, mais cela se passe incroyablement bien avec un flux de travail DVCS.

Answer 4

Une autre option si vous ne voulez pas vous fier aux extensions consiste à conserver localement un clone de votre référentiel en amont que vous n'utilisez que pour ces tâches d'intégration.

Dans votre exemple, vous pouvez simplement extraire / fusionner votre modification dans le référentiel d'intégration / en amont et la transférer directement sur le serveur distant.

Answer 5

Ce que j'utilise généralement, c'est de commettre un seul fichier:

 hg commit -m "commit message" filename

Si, plus tard, j'ai un conflit de fusion et que je ne suis toujours pas prêt à valider mes modifications, procédez comme suit:

1) Créez un fichier de correctif.

hg diff > changes.patch

2) Annulez toutes les modifications en attente non validées, uniquement après vérification du fichier de correctif.

hg revert --all

3) Extraire, mettre à jour et fusionner à la dernière révision

hg pull -u
hg merge
hg commit -m "local merge"

4) Importez simplement votre correctif et récupérez vos modifications.

hg import --no-commit changes.patch

N'oubliez pas d'utiliser l'indicateur -no-commit de la validation automatique des modifications.

Answer 6

Puisque vous avez dit le plus simple, j’utilise souvent hg commit -i (--interactive) même lors de la validation de fichiers entiers. Avec - interactive , vous pouvez simplement sélectionner le (s) fichier (s) souhaité (s) au lieu de saisir le (s) chemin (s) complet (s) sur la ligne de commande. En prime, vous pouvez même inclure / exclure sélectivement des morceaux dans les fichiers.

Et ensuite, il suffit de hg pousser pour envoyer le commit nouvellement créé.

Je mets plus de détails sur l'utilisation de hg commit --interactive dans cette réponse: https: // stackoverflow .com / a / 47931672/255961