22 votes

Est hg pull --rebase` analogue à "svn update"?

Cette question suppose il y a un "béni" référentiel central que les membres d'une équipe

  1. clone de
  2. push lorsqu'ils ont des contributions qu'ils veulent que les autres membres de l'équipe pour voir
  3. tirez à partir de quand ils veulent voir les contributions des autres.
  4. etc.

Si oui, je suppose hg update n'est pas analogue à l' svn update (pourquoi y aurait-il deux commandes qui font exactement la même chose?). De ce que j'ai pu rassembler, hg update plus comme svn revert. Est-ce exact?

Mise à jour:

Ma compréhension de rebase est en grande partie basée sur la "Un cas commun" de la section sur cette page:

http://mercurial.selenic.com/wiki/RebaseProject

41voto

Michael Ekstrand Points 12849

Comme d'autres l'ont indiqué, presque mais pas tout à fait. Dans l'ordre décroissant de similarité svn update (et de l'augmentation de l'observation générale DVCS, et plus précisément Mercurial, les meilleures pratiques[1]):

  1. hg pull -u (ou hg pull suivie par hg update) avec vos changements engagés et non engagés des changements depuis votre dernière pull. Ce n'est que près d' svn update que vous pouvez obtenir, mais il est assez mauvais DVCS pratique. L'une des subtilités de DVCS est que vous pouvez enregistrer vos modifications avant d'essayer de les fusionner avec d'autres, et ainsi avoir une version de sauvegarde de restauration et de réessayer de l'échec d'une fusion, et cette pratique donne ça. Ne pas le faire.

  2. hg pull --rebase après la validation de vos modifications. Ce tire les changements en amont, ré-applique vos changements sur le dessus d'eux et vous permet de pousser vos modifications comme une histoire linéaire. Le résultat final sera très similaire à une révision Subversion de l'histoire, mais vous obtenez le DVCS bénéficier de commettre avant de les fusionner. Je ne sais pas comment la sécurité de ce mode de fonctionnement compare entre Mercurial et Git, bien; dans Git, pré-rebase versions de vos modifications seront encore là jusqu'à ce que vous ne une git gc, mais Mercurial n'est pas explicite gc de filet de sécurité.

  3. hg pull suivie par hg merge avec vos changements déjà engagés à votre copie locale. C'est le traditionnel Mercurial pour la pratique de l'analogue fonctionnel de l' svn update, nonobstant la note de bas de page 1 ci-dessous. Il en résulte une version non linéaire de l'histoire, mais toutes les modifications sont suivies et inspectable.

Cela dit, il y a beaucoup de sagesse dans la pensée de Mercurial (et d'autres DVCSes) sur leurs propres termes, et ne cherche pas à traduire à partir de la Subversion/CVS-style de pensée.

  1. Si vous n'êtes pas de la réécriture de l'histoire-pour-garder-il-linéaire d'une école de pensée. Si vous êtes, alors rebase est probablement préférable d' update. L'Mercurial communauté tend à favoriser update.

11voto

Amber Points 159296

Pas exactement.

hg pull empoigne les révisions de l'autre référentiel et les ajoute à la disponibles localement des révisions dans votre copie de travail du dépôt, mais ne mettez pas à jour votre copie de travail uniquement de votre référentiel (qui, pour les DCVS comme hg/git/etc n'est pas la même chose qu'une copie de travail).

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

Cela diffère de la Subversion, car dans le svn, il n'y a pas une telle chose comme vos "référentiel local" - le seul référentiel est celui sur le serveur; vous n'avez qu'une copie de travail locale. Donc pourquoi update n'est qu'une commande unique, par opposition à de Mercurial pull puis update.

L'équivalent d' svn update pour Mercurial serait hg pull --update, ce qui est équivalent à hg pull puis hg update l'un après l'autre.

Un bout-à-bout de flux de travail pour DCVS avec une "centrale" repo ressemble à quelque chose comme ceci:

  1. A n' hg commit sur certains changements.
  2. A n' hg push pour pousser le référentiel central.
  3. B n' hg pull pour les tirer du référentiel central dans leur propre clone.
  4. B n' hg update de mettre à jour sa copie de travail afin de refléter les changements tiré dans leur clone.

Dans les systèmes sans une centrale repo, il serait plutôt de ressembler à quelque chose comme ceci:

  1. A n' hg commit sur certains changements.
  2. B, qui a cloné Un repo, veut que ces changements, et ne fait donc un hg pull directement à partir d'Un repo.
  3. B utilise hg update de mettre à jour sa copie de travail pour les modifications.

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

2voto

VonC Points 414372
hg pull --update

serait un équivalent de svn update

Comme décrit dans cette SORTE de question

La commande hg push et pull déplacer les changements entre les dépôts et update et commit se déplace changements entre votre copie de travail et de votre dépôt local.

Ainsi, dans un DVCS, vous avez 2 notions au lieu d'un:

  • local repo (pull/push)
  • répertoire de travail (qui est le seul de la représentation locale de la "pointe" d'une mise en pension avec SVN)

2voto

Decado Points 271

Voici un excellent guide pour débutants mercurial http://hginit.com/. Devrait expliquer plus clairement des choses. Commençant avec "Ne pas essayer et d'appliquer svn connaissance de vcs distribués de"!

2voto

Nick Pierpoint Points 7976

La commande hg pull --rebase n'est pas exactement analogue à l' 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 dans le référentiel fusionné avec tous les changements locaux. Si les fichiers de votre dépôt jusqu'à ce jour, mais vous pourriez encore avoir des modifications non validées.

Dans Mercurial, hg pull --rebase, obtenez les dernières modifications de la central repository " (ou quel que soit le référentiel, vous êtes en tirant à partir de) pour mettre à jour votre référentiel puis se déplacer le long de votre local s'engage. Vous aurez toujours besoin d'un hg update pour rendre votre copie de travail, le même que celui de votre référentiel local.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X