Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression. Avec Bazaar, ça m'arrive très souvent de commiter un truc que je sais être cassé, pour le réparer dans les commits suivants. Dans la branche principale, il n'y a pas de regression par contre.
Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
Un intérêt pratique est aussi pour la gestion des droits. Avec CVS/Subversion, un contributeur qui n'a pas les droits sur le repository est obligé d'envoyer ses contribution par patch. C'est la galère pour lui si il met du temps à mettre sa contribution au point et qu'il est obligé de faire des updates entre temps. Une solution est de lui donner les droits en commit sur le repository central, mais on n'aime pas donner les droits à n'importe qui non plus. Avec un gestionnaire de versions décentralisé, chacun a les droits sur son archive, et c'est tout. On peut travailler à plusieurs dans de bonnes conditions sans donner des droits à qui que ce soit (du moment que chacun a un bout d'espace web).
Pour aller plus loin, la gestion de version distribuée est un très bon moyen de favoriser la revue de code, et de garder une branche stable vraiment stable. C'est le point clé qui permet le développement de Linux comme on le connait depuis la version 2.6: Une nouvelle fonctionnalité est développée séparément, testée dans différentes branches, soumises à sa majestée Torvalds, qui en général t'enverra bouler « ton patch, il est pas bien, faut changer ça, ça, ça et ça ». Les demandes d'améliorations sont faites sur la branche dédiée à la fonctionalité en question, qui est maintenue un phase avec la branche principale. Un jour, le code est estimé comme étant de qualité suffisante et est intégré à la branche principale.
La gestion de version répartie, quand tu y as touché, tu as du mal à revenir à une gestion centralisée.
[^] # Re: Bazaar
Posté par Matthieu Moy (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 10.
Le plus gros à mon avis, c'est de pouvoir faire des commit réguliers qui ne dérangent pas les autres développeurs. Avec un gestionnaire de version centralisé et monobranche, on essaye en général de ne pas commiter si il y a eu regression. Avec Bazaar, ça m'arrive très souvent de commiter un truc que je sais être cassé, pour le réparer dans les commits suivants. Dans la branche principale, il n'y a pas de regression par contre.
Un autre intérêt, c'est de pouvoir travailler vraiment en local. Pour une machine connectée au net, ça veut dire de meilleures performances. Pour un portable qui n'est pas toujours connecté, ça veut dire pouvoir faire des choses infaisables autrement.
Un intérêt pratique est aussi pour la gestion des droits. Avec CVS/Subversion, un contributeur qui n'a pas les droits sur le repository est obligé d'envoyer ses contribution par patch. C'est la galère pour lui si il met du temps à mettre sa contribution au point et qu'il est obligé de faire des updates entre temps. Une solution est de lui donner les droits en commit sur le repository central, mais on n'aime pas donner les droits à n'importe qui non plus. Avec un gestionnaire de versions décentralisé, chacun a les droits sur son archive, et c'est tout. On peut travailler à plusieurs dans de bonnes conditions sans donner des droits à qui que ce soit (du moment que chacun a un bout d'espace web).
Pour aller plus loin, la gestion de version distribuée est un très bon moyen de favoriser la revue de code, et de garder une branche stable vraiment stable. C'est le point clé qui permet le développement de Linux comme on le connait depuis la version 2.6: Une nouvelle fonctionnalité est développée séparément, testée dans différentes branches, soumises à sa majestée Torvalds, qui en général t'enverra bouler « ton patch, il est pas bien, faut changer ça, ça, ça et ça ». Les demandes d'améliorations sont faites sur la branche dédiée à la fonctionalité en question, qui est maintenue un phase avec la branche principale. Un jour, le code est estimé comme étant de qualité suffisante et est intégré à la branche principale.
La gestion de version répartie, quand tu y as touché, tu as du mal à revenir à une gestion centralisée.