L'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.
Je ne suis pas certain que la puissance des merges découle de la nature centralisée ou non des VCS.
SVN ne gère pas les merges correctement simplement parce qu'il ne sait pas faire la différence entre une branche et une recopie ce qui mène à plein de cas tordus.
Ajoute à ca que le stockage correspond à une séquence linéaire de révisions. Pour un merge, ceci oblige à parcourir toutes les révisions une par une même celles qui ne concernent pas les fichiers des arbos à merger.
Clearcase ou Perforce, bien que centralisés, prennent très bien en charge les merges même si le stockage s'effectue au niveau des répertoires et des fichiers. Ce sont des objets avec un identifiant et un historique unique. Les merge 3 ways sont sûrs et les merge d'arborescences sont relativement aussi même s'ils sont bien plus lents car il necessite de descndre recursivement dans l'arboresence et de traiter les fichiers/répertoires un par un.
La puissance des DVCS type git, hg ou monotone vient du fait qu'ils stockent les révisions qui se succèdent ou qui forkent sous forme de graphes (DAGs) et que les branches sont des objets de première classe. Il est donc aisé de déterminer quelles révisions sont concernées par un merge.
Cette évolution est intervenue plus tard dans l'histoire des VCS, mais on pourrait très bien imaginer qu'un nouvel outil centralisé adopte une architecture identique. Seulement, à quoi servirait de créer un nouveau VCS centralisé sur cette base alors que les DVCS sont supérieurs sur tant d'autres aspects et qu'ils proposent toutes les fonctionnalités des VCS (à l'exception du verrou pessimiste).
[^] # Re: Les DVCS encouragent le travail collaboratif
Posté par El Titi . En réponse au journal Git malgré moi. Évalué à 3.
L'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.
Je ne suis pas certain que la puissance des merges découle de la nature centralisée ou non des VCS.
SVN ne gère pas les merges correctement simplement parce qu'il ne sait pas faire la différence entre une branche et une recopie ce qui mène à plein de cas tordus.
Ajoute à ca que le stockage correspond à une séquence linéaire de révisions. Pour un merge, ceci oblige à parcourir toutes les révisions une par une même celles qui ne concernent pas les fichiers des arbos à merger.
Clearcase ou Perforce, bien que centralisés, prennent très bien en charge les merges même si le stockage s'effectue au niveau des répertoires et des fichiers. Ce sont des objets avec un identifiant et un historique unique. Les merge 3 ways sont sûrs et les merge d'arborescences sont relativement aussi même s'ils sont bien plus lents car il necessite de descndre recursivement dans l'arboresence et de traiter les fichiers/répertoires un par un.
La puissance des DVCS type git, hg ou monotone vient du fait qu'ils stockent les révisions qui se succèdent ou qui forkent sous forme de graphes (DAGs) et que les branches sont des objets de première classe. Il est donc aisé de déterminer quelles révisions sont concernées par un merge.
Cette évolution est intervenue plus tard dans l'histoire des VCS, mais on pourrait très bien imaginer qu'un nouvel outil centralisé adopte une architecture identique. Seulement, à quoi servirait de créer un nouveau VCS centralisé sur cette base alors que les DVCS sont supérieurs sur tant d'autres aspects et qu'ils proposent toutes les fonctionnalités des VCS (à l'exception du verrou pessimiste).