Pourquoi est branchement et la fusion plus facile dans Mercurial que dans Subversion ?

Question

La gestion simultanée de plusieurs fusions sur les branches dans la Subversion ou CVS est juste une de ces choses qui doit être connu. Il est excessivement facile de garder une trace de branches et fusionne en Mercurial (et probablement de tout autre système distribué) mais je ne sais pas pourquoi. Quelqu'un d'autre sait?

Ma question vient du fait qu'avec Mercurial, vous pouvez adopter une méthode de travail similaire à celle de Subversions/CVSs référentiel central et tout fonctionnera tout aussi bien. Vous pouvez le faire de multiples fusions sur la même branche et vous n'aurez pas besoin d'interminables des bouts de papier avec la validation des numéros et des noms de balises.

Je sais que la dernière version de Subversion a la possibilité de suivre des fusions aux branches si vous n'obtenez pas tout à fait le même degré de tracas, mais il a été un énorme développement majeur de leur côté et il n'est toujours pas tout faire de l'équipe de développement voudrais qu'il fasse.

Il doit y avoir une différence fondamentale dans la façon dont tout cela fonctionne.

Answer 1

Dans Subversion (et CVS), le référentiel est d'abord et avant tout. Dans git et mercurial, il n'est pas vraiment la notion de référentiel dans l' même façon; c'est ici que les changements sont le thème central.

+1

Les tracas de CVS/SVN vient du fait que ces systèmes ne soient pas rappelez-vous le lien de parenté de changements. Dans Git et Mercurial, peut non seulement s'engager avez plusieurs enfants, il peut aussi avoir plusieurs les parents!

Qui peut facilement observée en utilisant l'un des outils graphiques, gitk ou hg view. Dans l'exemple suivant, la direction de la #2 a été forké #1 au commettre Un, et a depuis été fusionnés une fois (M, a fusionné avec la validation B):

o---A---o---B---o---C         (branch #1)
     \       \
      o---o---M---X---?       (branch #2)

Notez comment A et B ont deux enfants, tandis que M a deux parents. Ces les relations sont enregistrées dans le référentiel. Disons que le responsable de direction #2 maintenant veut fusionner les modifications les plus récentes à partir de la branche n ° 1, ils peuvent question d'une commande telle que:

$ git merge branch-1

et l'outil va automatiquement sais que la base est B-parce qu'il a été enregistré en commettre M, un ancêtre de la pointe du n ° 2--et qu'il a de fusionner ce qui s'est passé entre B et C. CVS ne pas enregistrer cette information, ni n'SVN avant la version 1.5. Dans ces systèmes, le graphique ressemblerait à:

o---A---o---B---o---C         (branch #1)
     \    
      o---o---M---X---?       (branch #2)

où M est juste un gigantesque "écrasé" s'engager de tout ce qui s'est passé entre A et B, appliqué sur le dessus de M. Remarque qu'après l'acte est fait, il n'y a pas de trace gauche (sauf éventuellement dans des commentaires plus lisibles) d'où M n' proviennent ni de la façon dont beaucoup s'engage étaient réduites-- l'histoire beaucoup plus impénétrable.

Pire encore, la réalisation d'une deuxième fusion devient un cauchemar: on doit comprendre ce que la fusion de la base était à l'époque de la première fusion (et on a à savoir qu'il y a eu une fusion, en premier lieu!), alors présent que les informations de l'outil, de sorte qu'il n'essaie pas de rejouer A..B sur haut de M. Tout cela est assez difficile lorsque l'on travaille en étroite collaboration, mais c'est tout simplement impossible dans un environnement distribué.

Une (relative) problème est qu'il n'y a aucun moyen de répondre à la question: "est-X contiennent des B?", où B est un potentiellement important de correction de bugs. Alors, pourquoi ne pas simplement enregistrer cette information dans le commit, depuis il est connu lors de la fusion de temps!

P.-S. -- je n'ai aucune expérience avec SVN 1.5+ de fusion capacités d'enregistrement, mais le flux de travail semble être beaucoup plus artificiel que dans les systèmes distribués. Si c'est effectivement le cas, c'est probablement parce que--comme mentionné dans le commentaire ci-dessus--l'accent est mis sur l'organisation du dépôt plutôt que sur les changements eux-mêmes.

Answer 2

Parce que Subversion (au moins version 1.4 et ci-dessous) n’est pas garder trace de ce qui ont été fusionné. Pour Subversion, fusion est fondamentalement la même comme un commit lors d’un autre contrôle de version comme Git, ce qui ont été fusionné sont mémorisés.

Answer 3

Sans intervention aucune de la de la déjà fourni des réponses, Hg offert supérieur capacités de fusion, car il utilise plus d'informations lors de la fusion des changements (de l'hginit.com):

Par exemple, si je change d'une fonction d'une peu à peu, puis le déplacer quelque part autre chose, la Subversion n'a pas vraiment d' rappelez-vous ces étapes, alors quand il s'agit le temps de fusion, on peut penser qu'une nouvelle fonction a juste montré hors de l' bleu. Alors qu'Mercurial souviendrez ces choses séparément: fonction changé, la fonction déplacé, ce qui signifie que si vous aussi vous avez changé de fonction un peu, il est beaucoup plus probable qu'Mercurial succès de fusion de nos changements.

Bien sûr, se souvenant de ce dernier a été fusionné (le point abordé par la plupart des réponses fournies ici) est aussi une grande victoire.

Les deux améliorations, cependant, sont discutables car subversion 1.5+ magasins supplémentaires de fusion de l'information sous la forme de propriétés subversion: l'information disponible, il n'y a aucune raison évidente pour laquelle la subversion de fusion ne pouvait pas mettre en œuvre de fusion avec autant de succès que Hg ou Git. Je ne sais pas si elle le fait, si, mais il semble que la subversion développeurs sont sur leur chemin pour obtenir autour de cette question.

Answer 4

Je suppose que cela pourrait être partiellement parce que Subversion a l’idée d’un serveur central ainsi qu’une ligne de temps absolu des révisions. Mercurial est réellement distribuée et n’a aucune telle référence à une ligne de temps absolu. Cela ne permet pas des projets Mercurial former des hiérarchies plus compliquées des branches pour l’ajout de fonctionnalités et essais cycles par sous-projet cependant équipes maintenant il fallait garder beaucoup plus activement sur le dessus de fusions se tenir au courant car ils ne peut pas frapper juste mise à jour et faire avec elle.

Answer 5

Dans Subversion (et CVS), le référentiel est avant tout. En git et mercurial, le concept de référentiel n’existe pas de la même manière; Ici, les changements sont le thème central.

Je n'ai pas beaucoup réfléchi à la manière de mettre en œuvre non plus, mais mon impression (basée sur une expérience amère et beaucoup de lecture) est que c'est cette différence qui rend la fusion et la création de branches beaucoup plus faciles dans les systèmes sans référentiel.