> Si j'utilise l'extension rebase, est ce que je verrai dans le dépôt central SVN tous mes commits ?
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.
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 GeneralZod . En réponse au message Hg et SVN: concaténer changesets en un seul commit. É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.