2010-01-26 8 views
10

Si je repasse le code depuis un moment et que j'ai oublié de créer une série de patchs, comment puis-je créer la série de patch rétrospectivement? Jusqu'à présent, la seule chose qui vient à l'esprit est:Comment diviser le travail en plusieurs patchs avec des files d'attente mercurielles?

# Prepare and test the first batch of changes. 
$ hg qrecord -m 'first batch' 1.patch 
$ hg qnew -m 'stash downstream changes' stash-1.patch 
$ hg qdelete -k temp-1.patch 
$ make hello 
cc  hello.c -o hello 
hello.c: In function ‘main’: 
hello.c:4: error: syntax error at end of input 
make: *** [hello] Error 1 
$ echo '}' >> hello.c 
$ make hello 
cc  hello.c -o hello 
$ hg qrefresh 

# Recover the stashed changes. 
$ patch -p1 < .hg/patches/last.patch 

# And around we go again! 
$ hg qrecord -m 'second batch' 2.patch 
$ hg qnew -m 'stash downstream changes' stash-2.patch 
$ hg qdelete -k stash-2.patch 
$ make hello 
... 

Cette approche très lourde est également dangereuse. Je pourrais oublier le -k sur qdelete, à quel point je vais me tapotter le front contre un mur de briques pendant plusieurs minutes, ou je pourrais inclure trop ou trop peu pendant l'opération de qrecord.

Y a-t-il un meilleur moyen?

(Ce que je voudrais vraiment être hg qpop juste avant un patch que je veux diviser, et utiliser une commande actuellement inexistante, hg qunrecord, pour aspirer interactivement les changements hors du patch dans mon répertoire de travail Une fois que je suis heureux avec les changements, hg qnew -f pourrait presser un nouveau patch en face de l'ancien.)

+0

Est-ce que cette question sur la division en différents correctifs par fichier? C'est à dire. les modifications pour un fichier donné ne sont pas réparties entre plusieurs correctifs. Parce que si c'est le cas, on peut faire mieux que l'approche que vous avez décrite ci-dessus. C'est une vieille question, mais toujours pertinente. –

+0

@FaheemMitha: Je suis passé à git il y a un certain temps, donc ce n'est pas particulièrement pertinent pour moi.Mais pour mémoire, je tiens certainement à différencier les changements dans les fichiers, en particulier les fichiers de projet de niveau supérieur qui contiennent souvent plusieurs ajouts/suppressions de fichiers sans rapport. En fait, c'est presque la norme plutôt que l'exception. –

+0

Ok. Merci pour les commentaires, Marcelo. –

Répondre

6

Le MQTutorial explique comment diviser les correctifs. Vous pouvez donc créer un patch à partir de votre travail actuel et le diviser en plusieurs patchs.

+0

Merci. Ce n'est pas une solution idéale, mais c'est beaucoup mieux que ce que j'ai fait jusqu'ici. –

+3

Ce que je fais habituellement est d'utiliser deux dépôts et un bel outil de comparaison visuelle comme Beyond Compare. En utilisant les noms dans le tutoriel, je commence par repo A avec OP appliqué, et je clone A à B. Puis dans AI 'qpop -a', diff A et B, cherry-choisir les changements pour P1 à copier de B à A , 'qnew -f P1', puis copiez le reste,' qnew -f P2'. –

2

Je pense que le crecord extension vous permettra de faire cela. Il vous donne une interface interactive basée sur les curses où vous pouvez choisir exactement ce qui est dans une validation.

+0

Basé sur une lecture rapide, crecord semble être un équivalent basé sur des curses à l'extension d'enregistrement. Merci d'avoir signalé cette extension, car elle semble assez pratique. Cependant, cela ne semble pas réduire le nombre d'étapes que je dois effectuer; cela rend le premier pas plus agréable. –

+1

@MarceloCantos, qcrecord ne réduit les étapes. Alors que qrecord me dit presque toujours "impossible d'éditer le patch pour tout le fichier", qcrecord me permet joyeusement d'exclure les "hunks" arbitraires dans mes patchs. –

2

TortoiseHg a fonction très utile « Hunk Sélection » en dialogue pour engager genre de ce travail:
http://tortoisehg.bitbucket.io/manual/2.0/commit.html#change-selection

+0

La plupart de mon travail n'est pas dans Windows, mais je l'utilise de temps en temps, donc je vous remercie pour le conseil. Malheureusement, comme pour la suggestion de @ RyanWilcox, cela semble faciliter la première étape de mon processus, plutôt que de simplifier le processus dans son ensemble. –

+2

FYI: Si besoin, vous pouvez exécuter TortoiseHg sur Linux et Mac OS :) http://bitbucket.org/tortoisehg/stable/wiki/install – kuy

+0

Je n'avais aucune idée! C'est bon à savoir. –

1

Activer les extensions intégrées:

[extensions] 
mq= 
record= 
shelve= 

Avancez ensuite MQ dans les changements de travail d'arbres et fourchues et supprimer patch d'origine:

$ hg qpop my.patch 
$ patch -p1 <.hg/patches/my.patch 

$ hg qnew -i my1.patch 
.... 
$ hg qnew -i my2.patch 
.... 
$ hg qnew myN.patch # last without interactive stuff 

$ hg qdelete --keep my.patch 

Entre my$i.patch et my$((i+1)).patch vous pouvez utiliser hg shelve/hg unshelve pour tester si le projet est construit et réussir les tests sur my$i.patch sans modifications ultérieures!

Si vous trouvez quelque chose qui manque sur cette étape, utilisez hg qref pour les modifications mises en attente ou hg qref -i pour les modifications non décorées!

Voir aussi Mercurial: move MQ patch to shelve?

0

D'abord, installer crecord car il est juste une façon de façon beaucoup plus beau fractionnement change vers le haut.

$ hg qcrecord part1 
$ hg qnew part2 # ok, slightly a lie at this point 
$ hg qpop 
$ echo "}" >> hello.c 
$ hg qrefresh 
$ hg qpush 
$ hg qcrefresh # Keep just what you want in part2 
$ ... 

La seule chose spéciale à crecord ici est la commande qcrefresh. Si vous n'êtes pas un fan de sorts, vous pouvez toujours faire tous les mêmes choses ici, il suffit de remplacer qcrefresh par hg qrefresh -X 're:.'. Ou hg qrefresh -I aauuuuuggghhh si vous préférez. (C'est votre "uncommit" en utilisant -X ou -I.)