Pourquoi la twig et la fusion sont-elles plus faciles dans Mercurial que dans Subversion?

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

+1

Le problème avec CVS ​​/ SVN vient du fait que ces systèmes ne se souviennent pas de la parenté des changements. Dans Git et Mercurial, non seulement un engagement peut avoir plusieurs enfants, mais il peut aussi avoir plusieurs parents!

Cela peut facilement être observé en utilisant l’un des outils graphiques, gitk ou hg view . Dans l’exemple suivant, la twig n ° 2 a été créée à partir de # 1 à la validation A et a été fusionnée une fois (à M, fusionnée 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, alors que M a deux parents . Ces relations sont enregistrées dans le référentiel. Disons que le responsable de la twig 2 veut maintenant fusionner les dernières modifications de la twig 1, il peut émettre une commande telle que:

 $ git merge branch-1 

et l’outil saura automatiquement que la base est B – parce qu’il a été enregistré dans commit M, ancêtre de la pointe de # 2 – et qu’il doit fusionner ce qui s’est passé entre B et C. CVS n’enregistre pas cette information , pas plus que SVN avant la version 1.5. Dans ces systèmes, le graphique ressemblerait à ceci:

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

où M est juste un gigantesque commit “écrasé” de tout ce qui s’est passé entre A et B, appliqué sur M. Notez qu’après l’exécution de l’acte, il ne rest plus de trace (sauf potentiellement dans les commentaires lisibles par l’homme) de M est né de, ni combien de commits ont été effondrés ensemble – rendant l’histoire beaucoup plus impénétrable.

Pire encore, effectuer une deuxième fusion devient un cauchemar: il faut savoir quelle était la base de fusion au moment de la première fusion (et il faut savoir qu’il ya eu une fusion au départ!) informations à l’outil afin qu’il ne tente pas de rejouer A..B au-dessus de M. Tout cela est assez difficile lorsque vous travaillez en étroite collaboration, mais est tout simplement impossible dans un environnement dissortingbué.

Un problème (apparenté) est qu’il n’y a aucun moyen de répondre à la question: “X contient-il B?” où B est un correctif de bogue potentiellement important. Alors, pourquoi ne pas simplement enregistrer cette information dans le commit, car elle est connue au moment de la fusion!

P.-S. – Je n’ai aucune expérience avec les capacités d’enregistrement de fusion SVN 1.5+, mais le workflow semble être beaucoup plus artificiel que dans les systèmes dissortingbués. Si tel est le cas, c’est probablement parce que, comme indiqué dans le commentaire ci-dessus, l’accent est mis sur l’organisation du référentiel plutôt que sur les changements eux-mêmes.

Parce que Subversion (au moins la version 1.4 et ci-dessous) ne garde pas une trace de ce qui a été fusionné. Pour Subversion, la fusion est fondamentalement la même que celle de tous les commit, alors que sur les autres contrôles de version comme Git, les éléments fusionnés sont mémorisés.

Indépendamment de toutes les réponses déjà fournies, Hg offrait des capacités de fusion supérieures, car il utilise davantage d’informations lors de la fusion des modifications ( hginit.com ):

Par exemple, si je modifie un peu la fonction, puis la déplace ailleurs, Subversion ne se souvient pas vraiment de ces étapes, alors quand vient le temps de fusionner, elle peut penser qu’une nouvelle fonction est apparue . Alors que Mercurial se souviendra de ces choses séparément: la fonction a changé, la fonction a été déplacée, ce qui signifie que si vous avez également modifié cette fonction, il est beaucoup plus probable que Mercurial fusionne avec succès nos changements.

Bien sûr, se souvenir de ce qui a été fusionné pour la dernière fois (le point abordé par la plupart des réponses fournies ici) est également une énorme victoire.

Cependant, les deux améliorations sont discutables car subversion 1.5+ stocke des informations de fusion supplémentaires sous la forme de propriétés de subversion: cette information disponible, il n’y a aucune raison évidente pour laquelle la fusion de subversion ne peut pas implémenter la fusion avec Hg ou Git. Je ne sais pas si c’est le cas, mais il semble certainement que les développeurs de subversion sont en passe de résoudre ce problème.

Je suppose que cela pourrait être dû en partie au fait que Subversion a l’idée d’un serveur central avec une ligne de temps absolue pour les révisions. Mercurial est vraiment dissortingbué et n’a aucune référence à une ligne de temps absolue. Cela permet aux projets Mercurial de former des hiérarchies de twigs plus compliquées pour l’ajout de fonctionnalités et de cycles de test par sous-projet, mais les équipes doivent désormais se tenir au courant des nouvelles fusions. .

Dans Subversion (et CVS), le référentiel est avant tout Dans git et mercurial, il n’ya pas vraiment le concept de référentiel 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 dont vous les implémenteriez, mais mon impression (basée sur une expérience amère et beaucoup de lecture) est que cette différence rend la fusion et la création de twigs beaucoup plus faciles dans des systèmes non basés sur des référentiels.

Je n’ai qu’une expérience avec Subversion mais je peux vous dire que l’écran de fusion de TortoiseSVN est terriblement compliqué. Heureusement, ils incluent un bouton de fonctionnement à sec afin que vous puissiez voir si vous le faites correctement. La complication réside dans la configuration de ce que vous voulez fusionner avec. Une fois que vous obtenez ce réglage pour la fusion, la fusion se passe généralement bien. Vous devez ensuite résoudre tous les conflits et ensuite valider votre copie de travail fusionnée dans le référentiel.

Si Mercurial peut faciliter la configuration de la fusion, je peux dire que cela faciliterait la fusion à 100% par rapport à Subversion.