Comparaison entre les systèmes de contrôle de version centralisés et distribués
Quels sont avantages et inconvénients avec l'utilisation des systèmes de contrôle de version centralisés par rapport aux systèmes distribués (DVCS)? Avez-vous rencontré des problèmes avec DVCS et comment vous êtes-vous protégé contre ces problèmes? Gardez l'outil de discussion agnostique et enflammé au minimum.
Pour ceux qui se demandent quels sont les outils DVCS disponibles, voici une liste des DVCS gratuits/open source les plus connus:
- Git , (écrit en C) utilisé par le Linux Kernel et Ruby on Rails .
- Mercurial , (écrit en Python) utilisé par Mozilla et OpenJDK .
- Bazaar , (écrit en Python) utilisé par développeurs Ubunt .
- Darcs , (écrit en Haskell).
De ma réponse à un autre question :
Les systèmes de contrôle de version distribués (DVCS) résolvent des problèmes différents de ceux des VCS centralisés. Les comparer, c'est comme comparer des marteaux et des tournevis.
VCS centralisé les systèmes sont conçus avec l'intention qu'il y ait une seule vraie source qui est bénie, et donc bonne. Tous les développeurs travaillent (extraction) à partir de cette source, puis ajoutent (valident) leurs modifications, qui deviennent alors de la même manière Blessed. La seule vraie différence entre CVS, Subversion, ClearCase, Perforce, VisualSourceSafe et tous les autres CVCS réside dans le flux de travail, les performances et l'intégration qu'offre chaque produit.
VCS distribué les systèmes sont conçus avec l'intention qu'un référentiel soit aussi bon que les autres, et que la fusion d'un référentiel à un autre ne soit qu'une autre forme de communication. Toute valeur sémantique quant au référentiel auquel faire confiance est imposée de l'extérieur par le processus, et non par le logiciel lui-même.
Le vrai choix entre l'utilisation d'un type ou de l'autre est organisationnel - si votre projet ou organisation veut un contrôle centralisé, alors un DVCS n'est pas un démarreur. Si vos développeurs sont censés travailler dans tout le pays/monde, sans connexions sécurisées à large bande à un référentiel central, alors DVCS est probablement votre salut. Si vous avez besoin des deux, vous êtes fsck.
Pour ceux qui pensent que les systèmes distribués n'autorisent pas les copies faisant autorité, veuillez noter qu'il existe de nombreux endroits où les systèmes distribués ont des copies faisant autorité, l'exemple parfait est probablement l'arbre du noyau de Linus. Bien sûr, beaucoup de gens ont leurs propres arbres, mais presque tous se dirigent vers l'arbre de Linus.
Cela dit, j'ai l'habitude de penser que les SCM distribués n'étaient utiles que pour de nombreux développeurs faisant des choses différentes, mais récemment, j'ai décidé que tout ce qu'un référentiel centralisé peut faire un référentiel distribué peut faire mieux.
Par exemple, supposons que vous soyez un développeur solo travaillant sur votre propre projet personnel. Un référentiel centralisé pourrait être un choix évident, mais envisagez ce scénario. Vous êtes loin de l'accès au réseau (en avion, dans un parc, etc.) et souhaitez travailler sur votre projet. Vous avez votre copie locale afin que vous puissiez bien travailler, mais vous voulez vraiment vous engager parce que vous avez terminé une fonctionnalité et que vous souhaitez passer à une autre, ou vous avez trouvé un bogue à corriger ou autre chose. Le fait est qu'avec un dépôt centralisé, vous finissez par écraser toutes les modifications et les valider dans un ensemble de modifications non logique ou vous les divisez manuellement plus tard.
Avec un repo distribué, vous continuez comme d'habitude, vous vous engagez, continuez, lorsque vous avez à nouveau accès au net, vous poussez vers votre "seul vrai repo" et rien n'a changé.
Sans parler de l'autre chose sympa à propos des dépôts distribués: l'historique complet est toujours disponible. Vous devez consulter les journaux de révision lorsque vous êtes loin du net? Vous devez annoter la source pour voir comment un bug a été introduit? Tout est possible avec des référentiels distribués.
S'il vous plaît, ne croyez pas que distribué vs centralisé concerne la propriété ou des copies faisant autorité ou quelque chose comme ça. La réalité distribuée est la prochaine étape de l'évolution des SCM.
Pas vraiment une comparaison, mais voici ce que les grands projets utilisent:
VCS centralisés
Apache, GCC, Ruby, MPlayer, Zope, Plone, Xiph, FreeBSD, WebKit, ...
[~ # ~] cvs [~ # ~]
CVS
VCS distribués
Noyau Linux, KDE, Perl, Ruby on Rails, Android, Wine, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnome, Samba, CUPS, GnuPG, Emacs ELPA .. .
Mozilla et Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, mutt, PETSc, Octave, FEniCS, Aptitude, Python, XEmacs, Xen, Vim, Xine ...
Emacs, Apt, Mailman, MySQL, Squid, ... également promus au sein d'Ubuntu.
ghc, ion, xmonad, ... populaire au sein de la communauté Haskell.
SQLite
W. Craig Trader a dit ceci à propos du DVCS et du CVCS:
Si vous avez besoin des deux, vous êtes fsck.
Je ne dirais pas que vous êtes fsck'd lorsque vous utilisez les deux. Les développeurs qui utilisent les outils DVCS essaient généralement de fusionner leurs modifications (ou d'envoyer des demandes de tirage) avec un emplacement central (généralement vers une branche de publication dans un référentiel de versions). Il y a une certaine ironie avec 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 au CVCS:
La notion de commits reconnaissables de manière unique rend l'envoi de correctifs entre pairs indolore. C'est à dire. vous créez le correctif en tant que commit et le partagez avec les autres développeurs qui en ont besoin. Plus tard, lorsque tout le monde veut fusionner, 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 version que vous utilisez. Malheureusement, dans le cas CVCS, le contrôle de version enregistrera les validations séparément, ne reconnaissant pas que les modifications sont les mêmes, ce qui augmente les chances de conflit de fusion.
Vous pouvez avoir des branches expérimentales locales (les référentiels clonés peuvent également être considérés comme une branche) que vous n'avez pas besoin de montrer aux autres. Cela signifie que la rupture des modifications n'a 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 devrez peut-être travailler hors ligne jusqu'à ce que vous l'ayez corrigé et valider les modifications d'ici là. Cette approche va à l'encontre de l'objectif d'utiliser le contrôle de version comme filet de sécurité, mais c'est un mal nécessaire dans CVCS.
Dans le monde d'aujourd'hui, les entreprises travaillent généralement avec des développeurs off-shore (ou encore mieux, elles souhaitent travailler à domicile). Le fait d'avoir un DVCS aide ce genre de projets car il élimine le besoin d'une connexion réseau fiable car chacun a son propre référentiel.
… Et quelques inconvénients qui ont généralement des solutions:
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 clairement évident. La solution de contournement utilise des règles de conduite, que les développeurs d'un projet doivent parvenir à un accord dans lequel repo pour fusionner leur travail.
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é qui peut se produire 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 souhaitent éviter les conflits de fusion. Cependant, le verrouillage présente 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 qu'avec un long modèle de transaction et ce n'est pas une garantie complète contre les conflits de fusion. Le seul moyen raisonnable, quel que soit le contrôle de version, est de lutter contre les gros conflits de fusion, c'est d'avoir une bonne architecture de code (comme un faible couplage et une forte cohésion) et de diviser vos tâches de travail afin 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 s'empare d'un référentiel cloné. La fuite de code source est une douleur intense pour les entreprises propriétaires. DVCS simplifie les choses car il vous suffit de cloner le référentiel, tandis que certains systèmes CM (comme ClearCase) essaient de restreindre cet accès. Cependant, à mon avis, si vous avez suffisamment de dysfonctionnements dans la culture de votre entreprise, aucun contrôle de version dans le monde ne vous aidera contre la fuite de code source.
Au cours de ma recherche du bon SCM, j'ai trouvé les liens suivants très utiles:
- Meilleure initiative SCM: comparaison . Comparaison d'environ 26 systèmes de contrôle de version.
- Comparaison des logiciels 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.
- Systèmes de contrôle de version distribués . Une autre comparaison, mais axée principalement sur les systèmes distribués.
Dans une certaine mesure, les deux régimes sont équivalents:
- Un VCS distribué peut simuler trivialement un VCS centralisé si vous envoyez 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 VCS distribué aussi naturellement, mais vous pouvez obtenir quelque chose de très similaire si vous utilisez quelque chose comme quilt en plus. Quilt, si vous ne le connaissez pas, est un outil pour gérer de grands ensembles de correctifs au-dessus d'un projet en amont. L'idée ici est que la commande DVCS commit est implémentée en créant un nouveau correctif, et la commande Push est implémentée en validant chaque correctif en attente sur le VCS centralisé puis en supprimant les fichiers de correctif. Cela semble un peu gênant, mais en pratique, cela fonctionne plutôt bien.
Cela dit, il y a quelques choses que les DVCS font traditionnellement très bien et que la plupart des VCS centralisés font un peu de hachage. Le plus important d'entre eux est probablement le branchement: un DVCS facilitera très facilement le branchement du référentiel ou la fusion de branches qui ne sont plus nécessaires, et gardera une trace de l'historique pendant que vous le faites. 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 tout à fait réussi. Que ce soit réellement un problème pour vous dépend de la façon dont vous allez organiser le développement, mais pour beaucoup de gens, c'est une considération importante.
L'autre avantage proposé 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 en voyage, cela pourrait être plus une considération pour vous.
Il n'y a en fait pas beaucoup de pièges spécifiques aux DVCS. Il y a une tendance légèrement plus grande pour les gens à se taire, car vous pouvez vous engager sans pousser et il est facile de finir de polir les choses en privé, mais à part cela, nous n'avons pas eu beaucoup de problèmes. Cela peut être dû au fait que nous avons un nombre important de développeurs open source, qui sont généralement familiers avec le modèle de développement de trading de patchs, mais les développeurs entrants de sources fermées semblent également prendre les choses assez rapidement.
Les VCS distribués sont attrayants à bien des égards, mais un inconvénient qui sera important pour mon entreprise est la question de la gestion des fichiers non fusionnables (généralement binaires, par exemple des documents Excel). Subversion résout ce problème en prenant en charge la propriété "svn: needs-lock", ce qui signifie que vous devez obtenir un verrou pour 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.
Donc, si vous souhaitez utiliser un DVCS, il n'est pas vraiment approprié pour gérer des fichiers non fusionnables.
J'utilise Subversion depuis de nombreuses années maintenant et j'en ai été très satisfait.
Ensuite, le buzz GIT a commencé et je devais juste le tester. Et pour moi, le principal argument de vente était la succursale. Oh mec. Maintenant, je n'ai plus besoin de nettoyer mon référentiel, de revenir en arrière avec quelques versions ou toutes les choses stupides que j'ai faites lors de l'utilisation de Subversion. Tout est bon marché en dvcs. Je n'ai essayé que Fossil et git, mais j'ai utilisé perforce, cvs et Subversion et il semble que les dvcs aient tous un branchement et un étiquetage vraiment bon marché. Plus besoin de copier tout le code d'un côté et donc la fusion est juste un jeu d'enfant.
Tout dvcs peut être configuré avec un serveur central, mais ce que vous obtenez est entre autres
Vous pouvez enregistrer n'importe quel petit changement que vous aimez, comme Linus le dit 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, la branche, la fusion, le clonage et le test localement sans que personne ne télécharge une énorme quantité de données. Et il vous suffit de pousser les dernières modifications sur le serveur central.
Et vous pouvez travailler sans réseau.
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 commander Git: http://git-scm.com/
Pour commander Fossil: http://www.Fossil-scm.org
Pour commander Mercurial: https://www.Mercurial-scm.org
Maintenant, je ne peux que recommander des systèmes dvcs, et vous pouvez facilement utiliser un serveur central
Le problème principal (à part le problème évident de bande passante) est propriété.
C'est pour être sûr que différents sites (géographiques) ne fonctionnent pas sur le même élément que l'autre.
Idéalement, l'outil est en mesure d'attribuer la propriété à un fichier, une branche ou même un référentiel.
Pour répondre aux commentaires de cette réponse, vous voulez vraiment que l'outil vous dise à qui appartient quoi, et puis communiquer (par téléphone, messagerie instantanée ou courrier) avec le site distant.
Si vous n'avez pas de mécanisme de propriété ... vous "communiquerez", mais souvent trop tard;) (c'est-à-dire: après avoir effectué un développement simultané sur un ensemble de fichiers identiques dans la même branche. )
Pour moi, c'est une autre discussion sur un goût personnel et c'est assez 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 Mercurial est écrit et la surcharge du réseau plus petit - juste pour dire quelques-unes de mes propres raisons.
Tout le monde ces jours-ci est dans le train de marche sur la façon dont les DVCS sont supérieurs, mais le commentaire de Craig est important. Dans un DVCS, chaque personne a toute l'histoire de la branche. Si vous travaillez avec de nombreux fichiers binaires (par exemple, des fichiers image ou des fichiers FLA), cela nécessite une énorme quantité d'espace et vous ne pouvez pas faire de différences.
J'ai le sentiment que Mercurial (et les autres DVCS) sont plus sophistiqués que ceux centralisés. Par exemple, la fusion d'une branche dans Mercurial conserve l'historique complet de la branche alors que dans SVN, vous devez aller dans le répertoire de la branche pour voir l'historique.
Un autre avantage du SCM distribué, même dans un scénario de développeur solo, est que vous, comme beaucoup d'entre nous, avez plus d'une machine sur laquelle vous travaillez.
Disons que vous avez un ensemble de scripts communs. Si chaque machine sur laquelle vous travaillez a un clone, vous pouvez mettre à jour à la demande et modifier vos scripts. Ça te donne:
- un gain de temps, surtout avec les touches ssh
- un moyen de brancher les différences entre différents systèmes (par exemple, Red Hat vs Debian, BSD vs Linux, etc.)
Un système centralisé ne vous empêche pas nécessairement d'utiliser des branches distinctes pour effectuer le développement. Il n'est pas nécessaire qu'il existe une seule copie fidèle de la base de code, mais différents développeurs ou équipes peuvent avoir différentes branches, des branches héritées peuvent exister, etc.
Cela signifie généralement que le référentiel est géré de manière centralisée - mais c'est généralement un avantage dans une entreprise dotée d'un service informatique compétent car cela signifie qu'il n'y a qu'un seul endroit pour sauvegarder et un seul endroit pour gérer le stockage.
La réponse de W. Craig Trader en résume la majeure partie, cependant, je trouve que le style de travail personnel fait également une énorme différence. Là où je travaille actuellement, nous utilisons Subversion comme notre seule vraie 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).