La différence centralisé vs décentralisé tient plutôt au mode d'organisation.
Un outil type CVS/SVN est très bien adapté pour le développement en entreprise ou la centralisation simplifie l'administration (sauvegardes, gestion des privilèges, ...) et renforce la sécurité (dev closed source).
Pour un développement opensource dans lequels les contributeurs viennent de tous horizons et peuvent être occasionnels, le fait de donner un accès en ecriture sur le serveur central peut devenir handicapant.
Pour récupérer des contributions, il faut soit ouvrir l'accès en écriture au repository, soit récupérer un patch et l'appliquer.
Avec un DVCS (Distributed Version Control System) chacun possède une copie (partielle ou complète) du repository et se syncrhronise à l'envi avec les autres. Un contributeur occasionnel crée des versions dans son repository local.
Les developpeurs du projet n'ont plus qu'à récuperer la branche du contributeur en synchronisant leur repository avec celui du contributeur et peuvent utilisant les commandes de merge/comparaison/historiques de l'outil. Ils n'ont donc pas à sortir de l'outil ni à donner de privilèges pour integrer des contrib occassionnelles.
La contrepartie est que le modèle de developpement est dit user-centric. Au final une seule personne doit integrer ou approuver toutes les contributions des autres.
C'est ce modèle de developpement qui convient à Linus Torvald pour le dev de Linux.
Pour les outils centralisé le modèle est dit repopsitory-centric car plusieurs contributeurs déclarés peuvent travailler en concurrence sur la même branche et donc intégrer, tester valider sur la même version. C'est pour ca que ces outils proposent des mécanismes de concurrence d'accès de façon à ce que celui qui commite n'écrase pas le travail des autres. Le fameux commit/checkin qui peut échouer car il faut résoudre un conflit de merge (schéma de concurrence optimiste)
[^] # Re: En résumé : Subversion pour faire simple ou Hg/Bzr pour faire puissa
Posté par golum . En réponse au journal Quel gestionnaire de révisions pour un "débutant". Évalué à 6.
Un outil type CVS/SVN est très bien adapté pour le développement en entreprise ou la centralisation simplifie l'administration (sauvegardes, gestion des privilèges, ...) et renforce la sécurité (dev closed source).
Pour un développement opensource dans lequels les contributeurs viennent de tous horizons et peuvent être occasionnels, le fait de donner un accès en ecriture sur le serveur central peut devenir handicapant.
Pour récupérer des contributions, il faut soit ouvrir l'accès en écriture au repository, soit récupérer un patch et l'appliquer.
Avec un DVCS (Distributed Version Control System) chacun possède une copie (partielle ou complète) du repository et se syncrhronise à l'envi avec les autres. Un contributeur occasionnel crée des versions dans son repository local.
Les developpeurs du projet n'ont plus qu'à récuperer la branche du contributeur en synchronisant leur repository avec celui du contributeur et peuvent utilisant les commandes de merge/comparaison/historiques de l'outil. Ils n'ont donc pas à sortir de l'outil ni à donner de privilèges pour integrer des contrib occassionnelles.
La contrepartie est que le modèle de developpement est dit user-centric. Au final une seule personne doit integrer ou approuver toutes les contributions des autres.
C'est ce modèle de developpement qui convient à Linus Torvald pour le dev de Linux.
Pour les outils centralisé le modèle est dit repopsitory-centric car plusieurs contributeurs déclarés peuvent travailler en concurrence sur la même branche et donc intégrer, tester valider sur la même version. C'est pour ca que ces outils proposent des mécanismes de concurrence d'accès de façon à ce que celui qui commite n'écrase pas le travail des autres. Le fameux commit/checkin qui peut échouer car il faut résoudre un conflit de merge (schéma de concurrence optimiste)