Est-ce que `hg pull --rebase` est analogue à `svn update`?

Question

Cette question suppose qu'il existe un dépôt central "béni" à partir duquel les membres d'une équipe

1. clonent
2. poussent lorsque ils ont des contributions qu'ils veulent que les autres membres de l'équipe voient
3. tirent lorsque ils veulent voir les contributions des autres.
4. etc.

Si c'est le cas, je suppose que hg update n'est pas analogue à svn update (pourquoi y aurait-il deux commandes qui font exactement la même chose?). D'après ce que je peux comprendre, hg update ressemble plus à svn revert. Est-ce correct?

Mise à jour:

Ma compréhension du rebase est largement basée sur la section "Un cas courant" de cette page :
https://www.mercurial-scm.org/wiki/RebaseProject

Answer 1

Comme d'autres l'ont indiqué, presque mais pas tout à fait. Dans l'ordre de similitude décroissante avec svn update (et de conformité croissante aux pratiques DVCS générales, et spécifiquement aux meilleures pratiques de Mercurial[1]) :

1. hg pull -u (ou hg pull suivi de hg update) avec vos modifications non encore validées et aucune modification validée depuis votre dernier pull. C'est aussi proche que possible de svn update, mais c'est une assez mauvaise pratique DVCS. Une des choses agréables des DVCS est que vous pouvez valider vos modifications avant de tenter de les fusionner avec d'autres, et ainsi avoir une version de sauvegarde pour faire un rollback et réessayer une fusion échouée, cette pratique l'abandonne. Ne le faites pas.

2. hg pull --rebase après avoir validé vos modifications. Cela tire les modifications en amont, réapplique vos modifications par dessus, et vous permet de repousser vos modifications en arrière comme une historique linéaire. Le résultat final ressemblera beaucoup à un historique de révision Subversion, mais vous obtenez le bénéfice des DVCS de valider avant de fusionner. Je ne sais pas comment la sécurité de ce mode de fonctionnement se compare entre Mercurial et Git, cependant ; dans Git, les versions pré-rebase de vos modifications seront toujours là tant que vous ne faites pas un git gc, mais Mercurial n'a pas de filet de sécurité gc explicite.

3. hg pull suivi de hg merge avec vos modifications déjà validées dans votre copie locale. C'est la pratique traditionnelle de Mercurial pour réaliser l'analogie fonctionnelle de svn update, nonobstant la note de bas de page 1 ci-dessous. Cela conduit à un historique de version non linéaire, mais toutes les modifications sont suivies et inspectables.

Ceci étant dit, il y a beaucoup de sagesse à penser à Mercurial (et aux autres DVCS) selon leurs propres termes, et ne pas essayer de traduire depuis la pensée de style Subversion/CVS.

1. Si vous n'êtes pas du genre à récrire l'historique pour le garder linéaire. Si c'est le cas, alors rebase est probablement préférable à update. La communauté de Mercurial tend à favoriser update.

Answer 2

Pas exactement.

hg pull récupère les révisions de l'autre dépôt et les ajoute aux révisions disponibles localement dans votre clone du dépôt, mais ne met pas à jour votre copie de travail - seulement votre dépôt (qui, pour les systèmes de contrôle de version distribués comme hg/git/etc, n'est pas la même chose qu'une copie de travail).

hg update met à jour votre copie de travail réelle à la dernière révision de votre dépôt local.

Cela diffère de Subversion car avec svn, il n'existe pas de "dépôt local" - le seul dépôt est celui sur le serveur ; vous n'avez qu'une copie de travail localement. C'est pourquoi update est une seule commande, contrairement à pull puis update de Mercurial.

L'équivalent de svn update pour Mercurial serait hg pull --update, ce qui équivaut à faire hg pull puis hg update l'une après l'autre.

Un flux de travail de bout en bout pour un système de contrôle de version distribué avec un dépôt "central" ressemble à ceci :

1. A fait un hg commit sur certains changements.
2. A fait un hg push pour les pousser vers le dépôt central.
3. B fait un hg pull pour les récupérer du dépôt central dans son propre clone.
4. B fait un hg update pour mettre à jour sa copie de travail afin de refléter les changements récupérés dans son clone.

Dans les systèmes sans dépôt central, cela ressemblerait plutôt à ceci :

1. A fait un hg commit sur certains changements.
2. B, qui a cloné le dépôt de A, veut ces changements, et fait donc un hg pull directement depuis le dépôt de A.
3. B utilise hg update pour mettre à jour sa copie de travail avec les changements.

Aussi, l'équivalent de svn revert est hg revert. :)

Answer 3

hg pull --update

serait l'équivalent de svn update

Comme décrit dans cette question SO

La commande hg push et pull transfèrent des modifications entre les dépôts et update et commit déplacent les modifications entre votre copie de travail et votre dépôt local.

Alors dans un système de contrôle de version décentralisé, vous avez 2 notions au lieu d'une :

• Dépôt local (pull/push)
• Répertoire de travail (qui est la seule représentation locale de la "pointe" d'un dépôt avec SVN)

Answer 4

Voici un excellent guide pour débutants sur Mercurial http://hginit.com/. Devrait expliquer la plupart des choses clairement. Commencez avec "Ne pas essayer d'appliquer les connaissances de svn aux systèmes de contrôle de version distribués"!

Answer 5

La commande hg pull --rebase n'est pas exactement analogique à svn update, mais le résultat peut être le même.

Dans Subversion, si vous mettez à jour votre copie de travail, vous obtenez les derniers changements du dépôt fusionnés avec les éventuels changements locaux. Ainsi, les fichiers de votre dépôt sont à jour mais vous pouvez toujours avoir des changements non confirmés.

Dans Mercurial, hg pull --rebase, obtiendra les derniers changements du 'dépôt central' (ou de n'importe quel dépôt à partir duquel vous tirez) pour mettre à jour votre dépôt puis réorganiser vos validations locales. Vous aurez toujours besoin d'un hg update pour rendre votre copie de travail identique à votre dépôt local.