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

Question

Quels sont les avantages et inconvénients de l’utilisation des systèmes de contrôle de version centralisés / distribués (DVCS)? Avez-vous rencontré des problèmes dans DVCS et comment vous êtes-vous protégé contre ces problèmes? Maintenez l'outil de discussion agnostique et flamboyant au minimum.

Pour ceux qui se demandent quels sont les outils DVCS 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

De ma réponse vers une autre question :

  

Systèmes de contrôle de version distribués   (DVCS) résolvent des problèmes différents de ceux   VCS centralisés. Les comparer est   comme comparer des marteaux et   tournevis.

     Les

systèmes VCS centralisés sont:   conçu avec l'intention qu'il y a   Une vraie source qui est bénie, et   donc bien. Tous les développeurs travaillent   (caisse) de cette source, puis   ajouter (commettre) leurs modifications, qui ensuite   devenir pareillement béni. Le seul   différence réelle entre CVS,   Subversion, ClearCase, Perforce,   VisualSourceSafe et tous les autres   CVCSes est dans le workflow,   la performance et l'intégration que chaque   offres de produits.

     Les

systèmes de VCS distribués sont   conçu avec l'intention que l'on   le référentiel est aussi bon que n'importe quel autre,   et qui fusionne d'un référentiel à   un autre ne sont qu'une autre forme de   la communication. Toute valeur sémantique comme   à quel référentiel doit être approuvé   est imposé de l'extérieur par   processus, pas par le logiciel lui-même.

     

Le vrai choix entre utiliser un seul type   ou l'autre est organisationnel - si   votre projet ou organisation veut   contrôle centralisé, alors un DVCS est un   non-starter. Si vos développeurs sont   devrait fonctionner partout dans le   pays / monde, sans sécurité   connexions haut débit à un central   référentiel, alors DVCS est probablement votre   salut. Si vous avez besoin des deux, vous êtes   fsck'd.

Answer 2

  

Pour ceux qui pensent que les systèmes distribués ne permettent pas de faire autorité   des copies s'il vous plaît noter qu'il y a beaucoup d'endroits où distribué   les systèmes ont des copies faisant autorité, le parfait exemple est probablement   L'arbre du noyau de Linus. Bien sûr, beaucoup de gens ont leurs propres arbres, mais   presque toutes se dirigent vers l'arbre de Linus.

     

Cela dit, j’avais l'habitude de penser que les GDS distribués n'étaient utiles que pour   beaucoup de développeurs font des choses différentes, mais ont récemment décidé   que tout ce qu'un référentiel centralisé peut faire un distribué peut faire   mieux.

     

Par exemple, disons que vous êtes un développeur solo travaillant sur votre propre   projet. Un référentiel centralisé pourrait être un choix évident, mais   considérez ce scénario. Vous êtes absent de l’accès au réseau (dans un avion,   dans un parc, etc.) et que vous souhaitez travailler sur votre projet. Vous avez votre local   copier afin que vous puissiez bien travailler, mais vous voulez vraiment vous engager parce que vous   avez terminé une fonction et souhaitez passer à une autre, ou vous avez trouvé   un bug à corriger ou autre chose. Le point est que avec un repo centralisé   vous finissez par écraser tous les changements et les engager   dans un changeset non logique ou vous les séparez manuellement plus tard.

     

Avec un repo distribué, vous poursuivez votre activité comme d'habitude, commettez, passez à autre chose,   lorsque vous avez à nouveau accès à Internet, vous appuyez sur votre "un véritable dépôt". et   rien n'a changé.

     

Sans parler de l’autre atout des points de vente distribués: complet   histoire disponible toujours. Vous devez consulter les journaux de révision lorsque   loin du net? Vous devez annoter la source pour voir comment un bogue   a été présenté? Tout est possible avec les pensions distribuées.

     

S'il vous plaît, ne croyez pas que la distribution vs centralisée est une question   la propriété ou des copies faisant autorité ou quelque chose comme ça. La réalité   est distribué est la prochaine étape dans l'évolution de 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 ...

• mercurial (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, ... ont également été promus au sein d’Ubuntu.

• darcs

  ghc, ion, xmonad, ... populaire dans la communauté Haskell.

• fossile

  SQLite

Answer 4

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

  

Si vous avez besoin des deux, vous êtes fsck'd.

Je ne dirais pas que vous êtes fsck'd lorsque vous utilisez les deux. Dans la pratique, les développeurs qui utilisent des outils DVCS tentent généralement de fusionner leurs modifications (ou d'envoyer des demandes d'extraction) à un emplacement central (généralement à une branche de version dans un référentiel de version). Il existe une certaine ironie chez les développeurs qui utilisent DVCS, mais au final, avec un flux de travail centralisé, vous pouvez commencer à vous demander si l’approche distribuée est vraiment meilleure que centralisée.

Le DVCS présente certains avantages par rapport à un CVCS:

• La notion de commits identifiables de manière unique permet d’envoyer des correctifs entre pairs sans difficulté. C'est à dire. vous faites le correctif comme un commit et vous le partagez avec les autres développeurs qui en ont besoin. Plus tard, lorsque tout le monde veut fusionner, cet engagement est reconnu et peut être comparé entre les branches, ce qui réduit les risques de fusion. Les développeurs ont tendance à s’envoyer des correctifs par clé USB ou par courrier électronique, quel que soit l’outil de gestion de versions utilisé. Malheureusement, dans le cas de CVCS, le contrôle de version enregistrera les commits comme distincts, sans reconnaître que les modifications sont identiques, ce qui augmente les risques de conflit de fusion.

• Vous pouvez avoir des branches expérimentales locales (les référentiels clonés peuvent également être considérées comme des branches) que vous n'avez pas besoin de montrer aux autres. Cela signifie que les changements de dernière minute n'ont pas besoin d'affecter les développeurs si vous n'avez rien poussé en amont. Dans un système CVCS, lorsque vous avez encore un changement important, vous devrez peut-être travailler hors connexion jusqu'à ce que vous le corrigiez, puis valider les modifications. Cette approche va à l’encontre de l’utilisation du contrôle de version comme filet de sécurité, mais c’est un mal nécessaire dans CVCS.

• Dans le monde actuel, les entreprises travaillent généralement avec des développeurs off-shore (ou même mieux encore, souhaitent travailler de chez eux). Avoir un DVCS facilite ce genre de projets car cela élimine le besoin d'une connexion réseau fiable puisque tout le monde a son propre référentiel.

& # 8230; et certains inconvénients qui présentent 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 parvenir à un accord permettant au référentiel de fusionner leurs travaux.

• Les verrous pessimistes, c'est-à-dire qu'un fichier est verrouillé lors d'une extraction, ne sont généralement pas possibles en raison de la simultanéité pouvant survenir entre les référentiels dans DVCS. La raison pour laquelle le verrouillage de fichier existe dans le contrôle de version est que les développeurs veulent éviter les conflits de fusion. Toutefois, le verrouillage présente l’inconvénient de ralentir le développement car deux développeurs ne peuvent pas travailler simultanément sur le même morceau de code, contrairement à un modèle de transaction longue, et ne constituent pas une garantie complète contre les conflits de fusion. Quel que soit le contrôle de version, le seul moyen sain de lutter contre les conflits de fusion est d’avoir une bonne architecture de code (comme un couplage faible, une cohésion élevée) et de diviser vos tâches pour 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. D'autant plus si un programmeur mécontent ou méchant s'empare d'un référentiel cloné. Les fuites de code source sont une douleur grave pour les entreprises propriétaires. Le format DVCS simplifie les choses car il vous suffit de cloner le référentiel, alors que certains systèmes CM (tels que ClearCase) tentent de restreindre cet accès. Cependant, à mon avis, si la culture de votre entreprise est suffisamment dysfonctionnelle, aucun contrôle de version dans le monde ne vous aidera à lutter contre les fuites de code source.

Answer 5

Lors de ma recherche du bon GDS, j’ai trouvé les liens suivants très utiles:

  
1. meilleure initiative en matière de gestion de la chaîne logistique: comparaison . Comparaison d’environ 26 systèmes de contrôle de version.
  
2. Comparaison du logiciel de contrôle de révision . Article Wikipedia comparant environ 38 systèmes de contrôle de version couvrant des sujets tels que les différences techniques, les fonctionnalités, les interfaces utilisateur, etc. "
  
3. Systèmes de contrôle de version distribués . Une autre comparaison, mais principalement axée sur les systèmes distribués.

Answer 6

Dans une certaine mesure, les deux systèmes sont équivalents:

• Un VCS distribué peut émuler trivialement un système centralisé si vous appliquez toujours vos modifications à un référentiel en amont désigné après chaque validation locale.
• Un VCS centralisé ne pourra généralement pas émuler un système distribué de manière tout aussi naturelle, mais vous pouvez obtenir quelque chose de très similaire si vous utilisez quelque chose comme quilt par-dessus. Quilt, si vous ne le connaissez pas bien, est un outil de gestion de grands ensembles de correctifs au-dessus de certains projets en amont. L'idée ici est que la commande de validation DVCS est implémentée en créant un nouveau correctif et que la commande push est implémentée en validant chaque correctif en suspens sur le VCS centralisé, puis en supprimant les fichiers de correctif. Cela semble un peu bizarre, mais dans la pratique, cela fonctionne plutôt bien.

Cela dit, il existe une ou deux choses que les DVCSE font traditionnellement très bien et que la plupart des VCS centralisés font un peu de hachage. Le plus important de ceux-ci est probablement la création de branches: un DVCS facilitera très facilement la création de branches du référentiel ou la fusion de branches qui ne sont plus nécessaires, et assurera le suivi de l'historique pendant que vous le ferez. Il n'y a aucune raison particulière pour laquelle un système centralisé aurait des problèmes avec cela, mais historiquement, personne ne semble avoir encore tout compris. La question de savoir si cela pose un problème pour vous dépend de la manière dont vous allez organiser le développement, mais pour beaucoup de gens, c'est une considération importante.

L’autre avantage des DVCS est qu’ils fonctionnent hors ligne. Je n'ai jamais vraiment eu beaucoup d'utilité pour cela; Je fais principalement du développement au bureau (donc le référentiel est sur le réseau local) ou à la maison (donc il y a l'ADSL). Si vous faites beaucoup de développement sur les ordinateurs portables lors de vos déplacements, cela pourrait être une considération plus importante pour vous.

Il n’ya pas vraiment beaucoup de pièges spécifiques aux DVCS. Les gens ont une tendance légèrement plus grande à rester silencieux, parce que vous pouvez vous engager sans pousser et qu'il est facile de finir de polir des choses en privé, mais à part cela, nous n'avons pas eu beaucoup de problèmes. Cela est peut-être dû au fait que nous avons un nombre important de développeurs open source, qui connaissent généralement bien le modèle de développement de patch-trading, mais les nouveaux développeurs de sources fermées semblent également relever rapidement le défi.

Answer 7

Les VCS distribués sont attrayants à bien des égards, mais l’un des inconvénients importants de mon entreprise est la gestion des fichiers non fusionnables (généralement des fichiers binaires, par exemple des documents Excel). Subversion résout ce problème en prenant en charge le fichier "svn: needs-lock". propriété, ce qui signifie que vous devez verrouiller le fichier non fusionnable avant de le modifier. Ça marche bien. Mais ce flux de travail nécessite un modèle de référentiel centralisé, ce qui est contraire au concept DVCS.

Ainsi, si vous souhaitez utiliser un DVCS, il ne convient pas vraiment de gérer des fichiers non fusionnables.

Answer 8

J'utilise la subversion depuis de nombreuses années et j'en étais vraiment heureux.

Ensuite, le buzz GIT a commencé et je devais le tester. Et pour moi, le principal argument de vente était la ramification. Oh mec. Maintenant, je n'ai plus besoin de nettoyer mon référentiel, de revenir en arrière avec quelques versions ou les choses stupides que j'ai faites lors de l'utilisation de la subversion. Tout est bon marché en dvcs. Cependant, j’ai seulement essayé fossile et git, mais j’ai utilisé forcément, cvs et subversion, et il semble que les dvcs aient tous des branchements et des marquages ??vraiment bon marché. Plus besoin de copier tout le code d'un côté, la fusion est donc un jeu d'enfant.

Tous les dvcs peuvent être configurés avec un serveur central, mais vous obtenez entre autres choses

Vous pouvez enregistrer n'importe quel petit changement, comme le dit Linus, si vous devez utiliser plus d'une phrase pour décrire ce que vous venez de faire, vous en faites trop. Vous pouvez vous débrouiller avec le code, les branches, les fusions, les clones et les tests localement sans que quiconque ne télécharge une quantité énorme de données. Et il vous suffit de transférer les dernières modifications dans le serveur central.

Et vous pouvez travailler sans réseau.

En bref, utiliser un contrôle de version est toujours une bonne chose. L'utilisation de dvcs est moins chère (en ko et en bande passante), et je pense que c'est plus amusant à utiliser.

Pour effectuer une commande sur Git: http://git-scm.com/
Pour accéder à Fossil: http://www.fossil-scm.org . Pour accéder à Mercurial: https://www.mercurial-scm.org

Maintenant, je ne peux que recommander les systèmes dvcs, et vous pouvez facilement utiliser un serveur central

Answer 9

Le principal problème (mis à part le problème évident de la bande passante) est la propriété .

C’est pour s’assurer que différents sites (géographiques) ne fonctionnent pas sur le même élément que l’autre.

Idéalement, l'outil peut attribuer la propriété d'un fichier, d'une branche ou même d'un référentiel.

Pour répondre aux commentaires de cette réponse, vous souhaitez vraiment que l'outil vous dise qui possède quoi et puis communiquez (par téléphone, messagerie instantanée ou courrier électronique) avec le site distant.
Si vous n'avez pas de mécanisme de propriété ... vous allez "communiquer", mais souvent trop tard;) (c.-à-d. Après avoir effectué un développement simultané sur un ensemble identique de fichiers dans la même branche. >

Answer 10

Pour moi, ceci est une autre discussion sur un goût personnel et il est plutôt difficile d’être vraiment objectif. Personnellement, je préfère Mercurial aux autres DVCS. J'aime écrire des crochets dans la même langue que celle utilisée pour Mercurial et réduire les frais généraux liés au réseau - rien que pour dire certaines de mes propres raisons.

Answer 11

De nos jours, tout le monde est partisan de la supériorité des DVCS, mais le commentaire de Craig est important. Dans un DVCS, chaque personne a toute l’histoire de la branche. Si vous travaillez avec un grand nombre de fichiers binaires (fichiers d’image ou FLA, par exemple), cela nécessite beaucoup d’espace et vous ne pouvez pas utiliser les diffs.

Answer 12

J'ai l'impression que Mercurial (et les autres DVCS) sont plus sophistiqués que les systèmes centralisés. Par exemple, la fusion d’une branche dans Mercurial conserve l’historique complet de celle-ci, tandis qu’en SVN, vous devez accéder au répertoire des branches pour consulter l’historique.

Answer 13

Un autre avantage pour la gestion de la chaîne logistique distribuée, même dans le scénario de développeur solo, est que si, comme beaucoup d’entre nous, vous travaillez sur plusieurs machines.

Disons que vous avez un ensemble de scripts communs. Si chaque machine sur laquelle vous travaillez a un clone, vous pouvez mettre à jour et modifier vos scripts à la demande. Cela vous donne:

1. un gain de temps, en particulier avec les touches ssh
2. un moyen de relier les différences entre différents systèmes (par exemple, Red Hat vs Debian, BSD vs Linux, etc)

Answer 14

W. La réponse de Craig Trader résume l'essentiel, cependant, je trouve que le style de travail personnel fait aussi une énorme différence. Là où je travaille actuellement, nous utilisons la subversion comme notre seule source. Cependant, de nombreux développeurs utilisent git-svn sur leurs machines personnelles pour compenser le problème de flux de travail que nous avons (échec de la gestion, mais c'est une autre histoire). Dans tout les cas. Il s’agit vraiment d’équilibrer les ensembles de fonctionnalités qui vous rendent le plus productif avec les besoins de l’organisation (authentification centralisée, par exemple).

Answer 15

Un système centralisé ne vous empêche pas nécessairement d’utiliser des branches distinctes pour le développement. Il n’est pas nécessaire de disposer d’une seule copie conforme de la base de code, mais différents développeurs ou équipes peuvent avoir différentes branches, des branches existantes peuvent exister, etc.

Cela signifie généralement que le référentiel est géré de manière centralisée - ce qui est généralement un avantage pour une entreprise dotée d'un service informatique compétent car cela signifie qu'il n'y a qu'un seul emplacement pour la sauvegarde et un seul emplacement pour la gestion du stockage.