Bonjour,
J'ai le problème suivant :
Je me suis installé un hg à moi pour pouvoir committer (désolé pour l'anglicisme, mais je n'ai rien trouvé de mieux) mes modifications en local au fur et à mesure de l'avancement de mes travaux.
Notre serveur de gestion de conf "officiel" est un serveur SVN.
Pas de problème, je peux faire des push/pull grâce à hgsubversion.
En revanche, j'aimerais pouvoir faire des commits fréquents "en local", et remonter tout ça vers le serveur SVN, mais en ne générant côté SVN qu'un seul commit.
L'idée est de garder pour moi l'historique de mes modifications, et de ne remonter dans le dépôt central qu'un seul commit lorsque "la peinture est suffisamment sèche"
J'ai vu qu'on pouvait jouer avec mq, mais je ne suis pas certain d'avoir tout bien compris (je débute avec hg).
Quelqu'un aurait-il une idée, un lien vers un tutoriel ?
Merci
Forum Astuces.divers Hg et SVN: concaténer changesets en un seul commit
8
nov.
2010
# Edition de l'historique
Posté par GeneralZod . Évalué à 5.
a) la méthode manuelle
Le principe est simple, tu veux combiner les changesets ]rev1, rev2] (note le sens des crochets
1. hg update rev1 # revenir à la révision 1 (index et répertoire de travail)
2. hg revert --all --rev rev2 # revenir à la révision 2 (répertoire de travail)
3. hg commit -m "combine rev1:rev2 changesets" # on commit l'ensemble des modifications en 1 changeset
L'inconvénient est que cette méthode crée une branche inutile (celle avec les commits non combinés), pour s'en débarrasser, soit tu clones le dépôt ou bien utiliser la commande strip fourni par l'extension mq.
b) la méthode mq
À peine plus compliqué que la précédente et beaucoup plus propre.
On suppose que tu as activé l'extension mq et initialiser le support dans le dépôt local
1. hg qimport rev1:rev2 # on confie à mq la gestion des changesets de rev1 à rev2
2. hg qgoto qbase # on applique le premier patch
3. hg qfold `hg qunapplied` # on combine tout les patchs non appliqués au dépôt, l'avantage c'est que tout les messages de commits sont concaténés
4. hg qfinish qbase # on repasse la gestion des changesets à mercurial
MQ est un peu le couteau suisse de mercurial (ça fait partie partie des outils à connaitre), il permet la gestion avancées de patchs comme Quilt, l'édition de l'historique, etc ... La différence avec la méthode précédente est qu'il n'y a rien qui traine dans le dépôt.
http://mercurial.selenic.com/wiki/MqExtension
c) histedit
Une extension non inclus en standard dédié à l'édition de l'historique (à la manière de git rebase --interactive). Je n'ai jamais utilisé cette extension celà dit, donc je me contenterais de signaler son existence.
http://mercurial.selenic.com/wiki/HisteditExtension
[^] # Re: Edition de l'historique
Posté par bat13 . Évalué à 3.
J'avais un temps commencé à "jouer" avec git, et j'avais vu qu'il était possible de "fusionner" plusieurs changesets, je me demandais s'il était possible de faire la même chose avec hg.
Depuis mon post sur le forum, j'ai fait quelques hg pull depuis le dépôt central, et à chaque fois, alors que les fichiers mis à jour n'ont rien à voir avec ceux sur lesquels j'ai bossé, j'ai du faire un hg merge ou hg --check, puis un hg ci. Et à chaque fois, toutes les modifications que j'avais apportées depuis le début (je n'ai encore pas fait de hg push) ont été re committées.
Je pense donc que je n'ai pas besoin d'utiliser ces techniques, car lorsque mon code sera prêt, je vais devoir faire un hg pull, puis un hg merge, un hg ci et enfin un hg push qui remontera mes modifications dans le dépôt central en un seul commit.
Mais je pense que ce phénomène est dû au fait que j'utilise l'extension hgsubversion uniquement.
Et dans d'autres cas d'utilisation, j'utiliserai sans doute ta méthode mq qui me parait vraiment propre.
Merci !
[^] # Re: Edition de l'historique
Posté par GeneralZod . Évalué à 2.
Je te conseille d'utiliser l'extension standard rebase pour rebaser tes changesets sur ceux du serveur. Ça rajoute la commande rebase et l'option --rebase à la commande pull avec un fonctionnement similaire à Git.
Tu peux également le faire avec mq (qui tu l'auras compris est le couteau suisse de mercurial), il suffit d'importer tes changesets dans une queue et les réimporter sur le nouveau tip. Les deux méthodes se valent, la première est probablement plus simple pour ceux qui ne sont pas habitués à mq.
Même si mercurial n'inclut par défaut le rebasing, c'est considéré comme une bonne pratique dans la communauté mercurial. Contrairement au merge, le rebasing permet d'avoir un historique plus "propre" en éliminant les changesets propre au merge.
[^] # Re: Edition de l'historique
Posté par bat13 . Évalué à 1.
Parce que ce qui me semble être le fonctionnement actuel, à savoir un commit (lors du push) qui rassemble tous mes commits locaux, ça me convient parfaitement.
On doit respecter un formalisme dans les messages de commit SVN que je ne respecte pas en local.
Existe-t-il quelque part un bon tutoriel si possible dans la langue de Mr Poquelin sur l'utilisation de hg et toutes les astuces possibles, et notamment mq ?
Pour m'être abonné à la liste de diffusion de tortoiseHg, je sais qu'il y a un sacré paquets de bugs signalés et corrigés, j'imagine donc que les possibilités de hg et de tortoiseHg évoluent sans cesse, ce ne doit pas être évident de trouver une doc à jour.
Merci
[^] # Re: Edition de l'historique
Posté par GeneralZod . Évalué à 2.
Rien à voir, l'opération rebase consiste à importer en local les nouveaux changesets effectués sur le dépôt distant puis changer le parent des changesets locaux
a) avant le rebase
sur le serveur (B est le dernier changeset commun aux deux dépôt)
A ---> B ---> C ---> D
en local:
A ---> B ---> E ---> F
b) après le rebase
en local (rien n'a changé sur le serveur)
A ---> B ---> C ----> D ---> E' ---> F'
Si tu avais fait un pull, tu aurais eu:
A ---> B ---> C ---> D
\\\\\\\\\\ |---> E ---> F
Et ensuite, il faudrait faire un merge des deux branches (donc un nouveau commit, ce qui devient rapidement désagréable, GNOME et Mozilla encouragent à faire un rebase avant de proposer un nouveau patch entre autre pour cette raison)
C) push
sur le serveur et en local:
A ---> B ---> C ----> D ---> E' ---> F'
> On doit respecter un formalisme dans les messages de commit SVN que je ne respecte pas en local.
Je te conseille de rebaser, ça te simplifiera d'autant plus la tâche que tu dois respecter des guidelines pour tes messages de commits sur le dépôt distant.
> Existe-t-il quelque part un bon tutoriel si possible dans la langue de Mr Poquelin sur l'utilisation de hg et toutes les astuces possibles, et notamment mq ?
http://mercurial.selenic.com/wiki/FrenchTutorial ===> le tutoriel officiel en français
http://bitbucket.org/rpelisse/hgbook-fr/ ====> la traduction du hg book
http://doc.fedora-fr.org/wiki/Gestion_et_contr%C3%B4le_de_ve(...) ===> le tutoriel de mes amis de fedora-fr
http://dblugeon.developpez.com/tutoriel/mercurial/intro/ ===> un autre tutoriel de chez developpez.com
Je te l'accorde la littérature francophone n'est pas très prolixe autour de mercurial.
> j'imagine donc que les possibilités de hg et de tortoiseHg évoluent sans cesse
Je ne suis pas familier avec tortoisehg, mais tu peux considérer que depuis la version 1.1 (sortie en 2008), la sémantique des commandes de base et le format de dépôt n'a pas évolué.
Les principales nouveautés depuis (hormis l'amélioration des performances, les quelques nouvelles commandes et extensions) sont la possibilité de fermer explicitement une branche et les dépôts imbriqués.
[^] # Re: Edition de l'historique
Posté par bat13 . Évalué à 1.
Pourtant, dans mon cas d'utilisation actuel, je pense continuer à travailler en pull+merge+commit, parce que ça me permet de conserver en local un historique plus fin que celui du dépôt central. Le seul commit qui devra respecter le formalisme "SVN" sera le dernier avant push.
Ceci n'est vrai qu'à l'instant présent, parce que je travaille sur de nouvelles fonctionnalités, et qu'elles ne seront intégrables au dépôt qu'un fois totalement prêtes.
En revanche, pour des travaux "habituels" (correction de bugs, petites évolutions, ...), j'utiliserai avec joie le rebase, ce qui me permettra d'utiliser hg et de me passer de svn !
Merci pour les tutos, le seul que je ne connaissais pas du tout c'est le hgbook en français.
[^] # Re: Edition de l'historique
Posté par bat13 . Évalué à 1.
Ca parait magique tellement c'est simple !
Bon, OK, ma modification ne touchait que deux lignes de code, mais sur le principe, tout parait limpide !
Un grand merci pour ton aide, je sens que je vais l'aimer, ce couple hg + hgsubversion + rebase :-)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.