> je ne vois pas comment BK pouvait être meilleur que le classique 3-way merge, mais je doit manquer d'imagination!
Je ne connais pas trop BK (jamais utilisé), mais le merge de base est une forme de 3-way merge.
En fait, une des grosses difficultés, c'est plus la recherche de l'ancetre commun que le merge lui-même (qui est un problème relativement bien résolu aujourd'hui, même si il y a encore des cas ou on pourrait faire mieux). Pour ça, il faut garder un historique de qui a mergé qui, qui est une branche de qui, ... ce que CVS par exemple ne fait pas. Il faut aussi un système de nommage qui permette de garantir l'unicité du nom sans pour autant qu'il n'y ai d'autorité centralisée d'attribution des noms (l'information "j'ai mergé avec toto version 42" n'est intéressante que si il y n'y a qu'un seul "toto" au monde ...). D'ou les histoires de SHA1 pour git et les adresses email dans les noms d'archives GNU Arch.
[^] # Re: Subversion vs GIT
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 5.
Je ne connais pas trop BK (jamais utilisé), mais le merge de base est une forme de 3-way merge.
En fait, une des grosses difficultés, c'est plus la recherche de l'ancetre commun que le merge lui-même (qui est un problème relativement bien résolu aujourd'hui, même si il y a encore des cas ou on pourrait faire mieux). Pour ça, il faut garder un historique de qui a mergé qui, qui est une branche de qui, ... ce que CVS par exemple ne fait pas. Il faut aussi un système de nommage qui permette de garantir l'unicité du nom sans pour autant qu'il n'y ai d'autorité centralisée d'attribution des noms (l'information "j'ai mergé avec toto version 42" n'est intéressante que si il y n'y a qu'un seul "toto" au monde ...). D'ou les histoires de SHA1 pour git et les adresses email dans les noms d'archives GNU Arch.