L'inconvénient de la fusion dans SVN avant la version 1.5 est-il désormais obsolète lorsque le manque de métadonnées n'est plus le cas?

11

Je commence avec SVN et de nombreuses sources disent que la fusion est très difficile dans SVN par rapport aux outils DVCS. Les questions les plus récentes que j'ai pu trouver ici sur SE datent de 2012.

Parfois, il est mentionné que la raison en est que SVN avant la v1.5 n'avait pas de métadonnées, mais SVN est maintenant à la version 1.8.9.

Étant donné que SVN est maintenant beaucoup plus mature que v1.5, et en particulier le fait que nous n'avons pas utilisé SVN 1.5 afin de ne pas souffrir du manque de métadonnées mentionné - y a-t-il encore beaucoup de validité dans ces arguments contre SVN?

Je comprends que DVCS a une approche complètement différente qui est souvent plus souhaitable, mais pour ceux qui "doivent" utiliser SVN pour une raison quelconque, la fusion n'est plus vraiment "l'enfer", n'est-ce pas?

version-control svn merging Torben Gundtofte-Bruun
la source
3
@ TorbenGundtofte-Bruun - Je n'ai pas le temps pour le moment de donner une telle réponse, mais je dirai "ne craignez pas SVN". Il a des limites, mais les DVCS aussi.
kdgregory

Réponses:

15

Cela fonctionne bien si vous vous en tenez aux cas simples , mais il y en a des complexes qui ne le font pas.

Les limites auxquelles je peux penser:

  • Il ne peut trouver l'ancêtre le plus récent que s'il se trouve sur l'une des branches impliquées. Donc, si vous créez branches/thiset les branches/thatdeux à partir de trunk, puis essayez de fusionner branches/thisvers branches/that, il ne saura pas quoi faire. Ce qui signifie que vous ne pouvez fusionner que la branche vers ou depuis son parent. Vous pouvez rencontrer cela si vous démarrez deux branches de fonctionnalités et réalisez plus tard que les fonctionnalités sont interdépendantes et doivent les combiner.

  • Bien qu'il affirme qu'il peut suivre les renommages, la fusion de branches lorsque des fichiers ont été déplacés d'un côté et modifiés de l'autre ne trouve pas toujours les bons fichiers à fusionner et les réparer manuellement est quelque peu fastidieux car il ne laisse pas les informations nécessaires n'importe où dans main.

  • Les fichiers ajoutés provoquent parfois de faux conflits lors de fusions ultérieures.

  • Étant donné que la subversion n'a pas de concept de branche distinct, vous ne pouvez fusionner qu'un sous-arbre d'un projet et cela peut conduire à de gros dégâts assez rapidement. Il est fortement recommandé de prendre soin de toujours fusionner les branches complètes. Malheureusement, pour une raison ou une autre, les propriétés des informations de fusion apparaissent parfois dans les sous-répertoires même si elles semblent superflues et que la fusion a été correctement effectuée pour toute la branche.

  • Enfin et surtout, il est lent . Les fusions sur un projet de n'importe quelle taille sérieuse prennent souvent des minutes où la plupart des DVCS peuvent le faire en moins d' une seconde.

Jan Hudec
la source
+1, excellente réponse. Le point concernant l'ancêtre commun est quelque chose que je devrai rechercher. Avez-vous des références pour ces faits?
Doval
1
@Doval: Expérience.
Jan Hudec
peut également être utile de mentionner que svn n'a pas non plus de concept distinct de balises
jk.
En ce qui concerne votre première puce (merci pour une explication très claire!), Cela ne pourrait-il pas être résolu en utilisant une branche d'accumulation qui a le même point de branche que les branches de fonctionnalité? (basé sur Vance98 ) Le problème ne se produit-il vraiment que lorsque les deux branches de fonction ont des points de branche différents?
Torben Gundtofte-Bruun
@ TorbenGundtofte-Bruun: l'ancêtre commun le plus récent ne doit pas nécessairement être un point de branchement. Vous pouvez le trouver vous-même et dire à subversion d'appliquer des changements entre des révisions de pions spécifiques. Mais le problème est que c'est beaucoup de travail et vous devez réaliser que vous devez le faire, parce que la subversion ne lâche pas nécessairement ses mains en disant qu'elle ne peut pas fusionner. Au lieu de cela, il peut trouver un ancêtre commun qui n'est pas le plus récent et générer de nombreux conflits.
Jan Hudec
1

D'après mon expérience, la fusion dans SVN a été «corrigée» dans la version 1.6. Je travaille à la fois dans Mercurial et SVN, et depuis la version 1.6 de SVN, la fusion semble être à peu près la même quantité de travail sur les deux plates-formes. La seule exception pourrait être que vous devez vous rappeler de fournir l' --reintegrateoption lors de la fusion d'une branche dans le tronc à l'aide de SVN.

Ce n'est que mon expérience opérationnelle. Je ne sais rien des internes de SVN.

Charles E. Grant
la source
2
Heureusement, 1.8 peut enfin détecter le cas de "réintégration". Mais cela ne prend en charge que l'ancêtre commun le plus récent sur local ou distant. Il ne peut toujours pas le trouver sur la troisième branche.
Jan Hudec