Comparaison entre les systèmes de contrôle de version centralisés et distribués

Question

Quels sont les avantages et inconvénients en utilisant Centralisé ou distribué Systèmes de contrôle de version (DVCS) ? Avez-vous rencontré des problèmes avec les DVCS et comment vous êtes-vous prémuni contre ces problèmes ? Gardez l'outil de discussion agnostique et le flaming au minimum.

Pour ceux qui se demandent quels outils DVCS sont disponibles, voici une liste des DVCS libres/open source les plus connus :

• Git (écrit en C) utilisé par le Noyau Linux et Ruby on Rails .
• Mercurial (écrit en Python) utilisé par Mozilla et OpenJDK .
• Bazaar (écrit en Python) utilisé par Développeurs Ubuntu .
• Darcs (écrit en Haskell).

Answer 1

Desde ma réponse à un autre question :

Systèmes de contrôle de version distribués (DVCSs) résolvent des problèmes différents de ceux VCS centralisés. Les comparer, c'est comme comparer un marteau et un tournevis.

VCS centralisé systèmes sont conçus dans l'intention qu'il y ait une seule vraie source qui est bénie, et donc bonne. Tous les développeurs travaillent (checkout) à partir de cette source, et ensuite ajoutent (commit) leurs modifications, qui deviennent alors deviennent pareillement bénis. La seule différence réelle entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe et tous les autres CVCSes est dans le flux de travail, performance, et l'intégration que chaque produit offre.

VCS distribué Les systèmes sont conçus avec l'intention qu'un référentiel est aussi bon qu'un autre, et que les fusions d'un référentiel à un autre sont juste une autre forme de communication. Toute valeur sémantique quant à quant à quel référentiel devrait être fiable est imposée de l'extérieur par processus, et non par le logiciel lui-même.

Le véritable choix entre l'utilisation d'un type ou l'autre est d'ordre organisationnel - si votre projet ou votre organisation souhaite un contrôle centralisé, alors un DVCS est un bon choix. n'est pas une solution. Si vos développeurs sont sont censés travailler partout dans le pays ou dans le monde entier, sans connexions haut débit sécurisées à un référentiel central, alors le DVCS est probablement votre salut. Si vous avez besoin des deux, vous êtes fscké.

Answer 2

A ceux qui pensent que les systèmes distribués ne permettent pas de faire autorité. veuillez noter qu'il y a beaucoup d'endroits où des systèmes distribués distribués ont des copies qui font autorité, l'exemple parfait est probablement l'arbre du noyau de Linus. Bien sûr beaucoup de gens ont leurs propres arbres mais mais presque tous vont vers l'arbre de Linus.

Cela dit, j'ai toujours pensé que les SCM distribués n'étaient utiles que pour beaucoup de développeurs faisant des choses différentes mais j'ai récemment décidé que tout ce qu'un référentiel centralisé peut faire, un référentiel distribué peut le faire mieux.

Par exemple, disons que vous êtes un développeur solo travaillant sur votre propre personnel. Un référentiel centralisé pourrait être un choix évident mais mais considérez ce scénario. Vous êtes loin de tout accès réseau (dans un avion, dans un parc, etc.) et vous voulez travailler sur votre projet. Vous avez votre copie locale Vous avez votre copie locale et vous pouvez travailler sans problème mais vous voulez vraiment commettre parce que vous parce que vous avez terminé une fonctionnalité et voulez passer à une autre, ou vous avez trouvé un bug à corriger ou autre. Le point est qu'avec un repo centralisé vous finissez soit par écraser tous les changements ensemble et les commiter dans un changeset non logique ou vous les divisez manuellement plus tard.

Avec un dépôt distribué, on fait comme d'habitude, on commet, on passe à autre chose, quand vous avez à nouveau accès à Internet vous poussez vers votre "seul vrai repo" et rien n'a changé.

Sans parler de l'autre point positif des dépôts distribués : l'historique complet historique complet disponible en permanence. Vous avez besoin de regarder les journaux de révision lorsque vous êtes loin du réseau ? Vous avez besoin d'annoter la source pour voir comment un bug a été introduit ? Tout cela est possible avec les dépôts distribués.

S'il vous plaît, ne croyez pas que distribué ou centralisé est une question de de propriété ou de copies d'autorité ou quoi que ce soit de ce genre. La réalité est que la distribution est la prochaine étape dans l'évolution des SCM.

Answer 3

Ce n'est pas vraiment une comparaison, mais voici ce que les grands projets utilisent :

VCS centralisés

• Subversion

  Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...

• CVS

  CVS

VCS distribués

• git

  Noyau Linux, KDE, Perl, Ruby on Rails, Android, Wine, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA...

• mercuriel (hg)

  Mozilla et Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, mutt, PETSc, Octave, FEniCS, Aptitude, Python, XEmacs, Xen, Vim, Xine...

• bzr

  Emacs, Apt, Mailman, MySQL, Squid, ... également promus au sein d'Ubuntu.

• darcs

  ghc, ion, xmonad, ... populaires au sein de la communauté Haskell.

• fossile

  SQLite

Answer 4

W. Craig Trader a dit ceci à propos du DVCS et du CVCS :

Si vous avez besoin des deux, vous êtes foutu.

Je ne dirais pas que vous êtes fscké lorsqu'on utilise les deux. En pratique, les développeurs qui utilisent des outils DVCS essaient généralement de fusionner leurs modifications (ou d'envoyer des demandes de retrait) vers un emplacement central (généralement vers une branche de publication dans un référentiel de publication). Il y a une certaine ironie chez les développeurs qui utilisent DVCS mais qui, en fin de compte, s'en tiennent à un flux de travail centralisé, on peut commencer à se demander si l'approche distribuée est vraiment meilleure que l'approche centralisée.

Le DVCS présente certains avantages par rapport au CVCS :

• La notion de commits reconnaissables de manière unique permet d'envoyer des correctifs entre pairs sans difficulté. C'est-à-dire que vous faites le patch comme un commit, et le partagez avec les autres développeurs qui en ont besoin. Plus tard, lorsque tout le monde veut fusionner ensemble, ce commit particulier est reconnu et peut être comparé entre les branches, ce qui réduit les risques de conflit de fusion. Les développeurs ont tendance à s'envoyer des correctifs par clé USB ou par e-mail, quel que soit l'outil de gestion des versions utilisé. Malheureusement, dans le cas de CVCS, le contrôle de version enregistrera les commits comme distincts, ne reconnaissant pas que les changements sont les mêmes, ce qui augmente le risque de conflit de fusion.

• Vous pouvez avoir des branches expérimentales locales (les dépôts clonés peuvent également être considérés comme une branche) que vous n'avez pas besoin de montrer aux autres. Cela signifie que les changements de rupture n'ont pas besoin d'affecter les développeurs si vous n'avez rien poussé en amont. Dans un CVCS, lorsque vous avez encore un changement de rupture, vous pouvez être amené à travailler hors ligne jusqu'à ce que vous l'ayez corrigé et à livrer les changements à ce moment-là. Cette approche va à l'encontre de l'objectif de l'utilisation du versioning comme filet de sécurité, mais c'est un mal nécessaire dans les CVCS.

• Dans le monde d'aujourd'hui, les entreprises travaillent généralement avec des développeurs délocalisés (ou, mieux encore, qui souhaitent travailler à domicile). L'utilisation d'un DVCS est utile pour ce type de projets car elle élimine le besoin d'une connexion réseau fiable, chacun ayant son propre dépôt.

et quelques inconvénients qui ont généralement des solutions de contournement :

• Qui a la dernière révision ? Dans un CVCS, le tronc a généralement la dernière révision, mais dans un DVCS, cela peut ne pas être évident. La solution de contournement consiste à utiliser des règles de conduite, selon lesquelles les développeurs d'un projet doivent se mettre d'accord sur le repo à partir duquel ils fusionnent leur travail.

• Les verrouillages pessimistes, c'est-à-dire qu'un fichier est verrouillé lors d'un check-out, ne sont généralement pas possibles en raison de la concurrence qui peut se produire entre les dépôts dans DVCS. La raison pour laquelle le verrouillage des fichiers existe dans le contrôle de version est que les développeurs veulent éviter les conflits de fusion. Cependant, le verrouillage a l'inconvénient de ralentir le développement car deux développeurs ne peuvent pas travailler sur le même morceau de code simultanément comme avec un modèle de transaction long et il n'est pas une garantie complète contre les conflits de fusion. Les seules façons saines, indépendamment du contrôle de version, de combattre les gros conflits de fusion sont d'avoir une bonne architecture de code (comme un couplage faible et une cohésion élevée) et de diviser les tâches de travail de manière à ce qu'elles aient un faible impact sur le code (ce qui est plus facile à dire qu'à faire).

• Dans les projets propriétaires, il serait désastreux que l'ensemble du référentiel devienne accessible au public. Encore plus si un programmeur mécontent ou malveillant met la main sur un dépôt cloné. Les fuites de code source sont une véritable plaie pour les entreprises propriétaires. Les DVCS simplifient les choses car il suffit de cloner le dépôt, tandis que certains systèmes de gestion de contenu (comme ClearCase) tentent de restreindre cet accès. Cependant, à mon avis, si la culture de votre entreprise est suffisamment dysfonctionnelle, aucun système de contrôle de version au monde ne vous aidera à lutter contre les fuites de code source.

Answer 5

Pendant ma recherche du bon SCM, j'ai trouvé les liens suivants d'une grande aide :

1. Meilleure initiative de gestion de la chaîne d'approvisionnement : Comparaison . Comparaison d'environ 26 systèmes de contrôle de version.
2. Comparaison des logiciels de contrôle de révision . Article de Wikipedia comparant 38 systèmes de contrôle de version, couvrant des sujets tels que les différences techniques, les fonctionnalités, les interfaces utilisateur, et plus encore.
3. Systèmes de contrôle de version distribués . Une autre comparaison, mais axée principalement sur les systèmes distribués.