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

à ceux qui pensent que les systèmes distribués ne permettent pas des copies, veuillez noter qu'il y a beaucoup d'endroits où distribués les systèmes ont des copies faisant autorité, l'exemple parfait est probablement L'arbre à grains de Linus. Sûr que beaucoup de gens ont leurs propres arbres, mais presque tous coulent vers L'arbre de Linus.

qui disait que j'avais l'habitude de penser que les SCM distribués n'étaient utiles que pour beaucoup de développeurs font des choses différentes mais récemment ont décidé que tout ce qu'un référentiel centralisé peut faire un système distribué, on peut faire mieux.

par exemple, dites que vous êtes un développeur solo travaillant sur votre propre projet. Un référentiel centralisé pourrait être un choix évident, mais considérons ce scénario. Vous êtes loin de l'accès au réseau (sur un plan, dans un parc, etc) et veulent travailler sur votre projet. Vous avez votre local copiez pour que vous puissiez faire du bon travail mais vous voulez vraiment vous engager parce que vous avoir terminé une fonctionnalité et que vous voulez passer à une autre, ou vous avez trouvé un bug à corriger ou quoi que ce soit. Le point est qu'avec un repo centralisé on finit soit par masquer tous les changements ensemble et les commettre dans un jeu de modifications non-logiques ou vous les séparez manuellement plus tard.

avec un rapport distribué vous allez sur les affaires comme d'habitude, s'engager, passer à autre chose, lorsque vous avez à nouveau accès au réseau, vous appuyez sur votre "one true repo" et rien n'a changé.

Sans parler de l'autre chose agréable sur les repos distribués: complet histoire disponible toujours. Vous devez regarder les journaux de révision quand loin de le net? Vous devez annoter la source pour voir comment un bug a été introduit? Tout est possible avec des repos distribués.

s'il vous Plaît s'il vous plaît ne crois pas que distribué vs centralisée est sur la propriété ou des copies autorisées ou quelque chose comme ça. Réalité la distribution est la prochaine étape de l'évolution des MCs.

pas vraiment une comparaison, mais voici ce que les grands projets utilisent:

Vcses Centralisées

• Subversion

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

• CVS

  CVS

Vcses Distribuées

• 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,... également promu au sein D'Ubuntu.

• darcs

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

• fossile

  SQLite

W. Craig Trader , a déclaré ceci au sujet de DVCS et CVC:

si vous avez besoin des deux, vous êtes fsck.

Je ne dirais pas que vous êtes fsck'd en utilisant les deux. En pratique, les développeurs qui utilisent les outils DVCS essaient généralement de fusionner leurs modifications (ou d'envoyer des requêtes pull) avec un emplacement central (généralement vers une branche de publication dans un dépôt de versions). Il y a une certaine ironie avec les développeurs qui utilise DVCS mais en fin de Compte coller avec un workflow centralisé, vous pouvez commencer à se demander si l'approche distribuée est vraiment mieux que centralisé.

il y a quelques avantages avec DVCS par rapport à CVCS:

• la notion de commits reconnaissables de façon unique rend l'envoi de patches entre pairs indolore. I. e. vous faites le patch comme un commit, et le partager avec d'autres développeurs qui en ont besoin. Plus tard, quand tout le monde veut fusionner ensemble, ce commit particulier est reconnu et peut être comparé entre les branches, ayant moins de chance de conflit de fusion. Les développeurs ont tendance à envoyer des correctifs les uns aux autres par clé USB ou e-mail indépendamment de l'outil de version que vous utilisez. Malheureusement, dans le cas du CVCS, le contrôle de version enregistrera les propagations séparément, ne reconnaissant pas que les modifications sont les mêmes, ce qui augmente le risque de conflit de fusion.

• Vous pouvez avoir des locaux les branches expérimentales (les dépôts clonés peuvent aussi être considérés comme une branche) que vous n'avez pas besoin de montrer aux autres. Cela signifie que casser les changements n'a pas besoin d'affecter les développeurs si vous n'avez pas poussé quoi que ce soit en amont. Dans un CVCS, lorsque vous avez encore un changement de rupture, vous pourriez devoir travailler hors ligne jusqu'à ce que vous l'ayez corrigé et engager les changements d'ici là. Cette approche va à l'encontre de l'objectif d'utiliser le versioning comme filet de sécurité, mais c'est un mal nécessaire dans les CVC.

• dans le monde d'aujourd'hui, les entreprises travaillent généralement avec des développeurs off-shore (ou si même mieux ils veulent travailler à partir de la maison). Avoir un DVCS aide ce genre de projets parce qu'il élimine le besoin d'une connexion réseau fiable puisque chacun a son propre repo.

... et certains inconvénients qui ont généralement des solutions de rechange:

• 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, ce n'est pas forcément évident. La solution est d'utiliser des règles de conduite, que les développeurs d'un projet doivent parvenir à un accord dans lequel repo pour fusionner leurs travaux contre.

• les serrures pessimistes, c.-à-d. qu'un fichier est verrouillé au moment de la sortie, ne sont généralement pas possibles en raison de la concurrence qui peut se produire entre les dépôts dans les DVCS. Le verrouillage des fichiers de motifs existe dans le contrôle de version est parce que les développeurs veulent é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 en même temps qu'avec un modèle de transaction long et ce n'est pas une garantie complète contre les conflits de fusion. La seule façon saine indépendamment du contrôle de version est de combattre les conflits de grande Fusion est d'avoir une bonne architecture de code (comme le couplage faible forte cohésion) et de diviser vos tâches de travail de sorte qu'ils avoir peu d'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 dépôt devienne accessible au public. Encore plus si un programmeur mécontent ou malveillant s'empare d'un dépôt cloné. La fuite de code Source est une grande douleur pour les entreprises propriétaires. Les DVCS simplifient tout cela, car vous n'avez besoin que de cloner le dépôt, tandis que certains systèmes CM (comme ClearCase) essaient de limiter l'accès. Cependant, à mon avis, si vous avez une quantité suffisante de dysfonctionnement dans votre culture d'entreprise, alors aucun contrôle de version dans le monde vous aidera contre la fuite de code source.

lors de ma recherche de la SCM droite, j'ai trouvé les liens suivants pour être d'une grande aide:

1. Mieux SCM Initiative : "Comparaison des 151950920" . Comparaison d'environ 26 systèmes de contrôle de version.
2. Comparaison de révision logiciel de contrôle . Article de Wikipedia comparant environ 38 systèmes de contrôle de version couvrant des sujets comme les différences techniques, les fonctionnalités, les interfaces utilisateur, et plus.
3. Distribué systèmes de contrôle de version . 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 trivialement émuler un VCS centralisé si vous poussez toujours vos modifications vers un dépôt en amont désigné après chaque propagation locale.
• un VCS centralisé ne sera généralement pas en mesure d'imiter un VCS distribué aussi naturellement, mais vous pouvez obtenir quelque chose de très similaire si vous utilisez quelque chose comme courtepointe sur le dessus de celui-ci. Quilt, si vous n'êtes pas familier avec elle, est un outil pour gérer de grands ensembles de correctifs sur le dessus de certains projet en amont. L'idée ici est que la commande DVCS commit est implémentée en créant un nouveau patch, et la commande push est implémentée en engageant chaque patch en suspens dans le VCS centralisé, puis en rejetant les fichiers de patch. Cela semble un peu maladroit, mais dans la pratique, cela fonctionne plutôt bien.

cela dit, il y a deux choses qui Les DVCSes se débrouillent traditionnellement très bien et la plupart des VCSes centralisées font un peu de hasch of. Le plus important est probablement la création de branches: un DVCS facilitera la création de branches dans le dépôt ou la fusion de branches qui ne sont plus nécessaires, et vous permettra de garder une trace de l'histoire pendant que vous le faites. Il n'y a pas de raison particulière pour qu'un système centralisé ait des problèmes avec cela, mais historiquement personne ne semble avoir tout à fait raison. Si c'est effectivement un problème pour vous dépend sur la façon dont vous allez organiser le développement, mais pour beaucoup, c'est une considération importante.

l'autre avantage des DVCSes est qu'elles fonctionnent hors ligne. Je n'ai jamais vraiment eu beaucoup d'utilité pour cela; je fais surtout du développement soit au bureau (donc le dépôt est sur le réseau local) ou à la maison (donc il y a ADSL). Si vous faites beaucoup de développement sur les ordinateurs portables tout en voyageant alors ce serait peut-être plus de considération pour vous.

là en fait, il n'y a pas beaucoup de gotchas qui sont spécifiques aux DVCSes. Il y a une tendance un peu plus grande pour les gens à rester silencieux, parce que vous pouvez vous engager sans pousser et il est facile de finir par polir des 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 patch-trading, mais les développeurs entrants de sources fermées semblent également prendre les choses en charge raisonnablement rapidement.

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 fusibles (généralement binaires, par exemple des documents Excel). Subversion gère cela en supportant la propriété "svn:needs-lock", ce qui signifie que vous devez obtenir une serrure pour le fichier non fusible avant de l'éditer. Il fonctionne bien. Mais ce flux de travail nécessite un modèle de dépôt centralisé, ce qui est contraire au concept de DVCS.

So si vous voulez utiliser un DVCS, il n'est pas vraiment approprié de gérer des fichiers qui ne sont pas fusionnables.

j'utilise subversion depuis de nombreuses années et j'en ai été très satisfait.

puis le buzz GIT a commencé et j'ai juste eu à le tester. Et pour moi, le principal argument de vente était la branche. Oh boy. Maintenant, je n'ai plus besoin de nettoyer mon dépôt, de revenir sur quelques versions ou toutes les bêtises que j'ai faites en utilisant subversion. Tout est bon marché dans dvcs. J'ai seulement essayé fossil et git, mais j'ai utilisé perforce, cvs et subversion et ça ressemble à des dvcs tous ont vraiment brancher et étiqueter bon marché. Plus besoin de copier tout le code d'un côté et donc la fusion est juste un jeu d'enfant.

N'importe quel dvcs peut être configuré avec un serveur central, mais ce que vous obtenez est entre autres choses

vous pouvez vérifier n'importe quel petit changement que vous aimez, comme le dit Linus si vous avez besoin d'utiliser plus d'une phrase pour décrire ce que vous venez de faire, vous faites trop. Vous pouvez avoir votre voie avec le code, la branche, la fusion, le clone et le test tous localement, sans provoquer quiconque de télécharger énorme quantité de données. Et vous n'avez qu'à pousser les modifications finales dans 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 KB et bande passante), et je pense qu'il est plus amusant à utiliser.

à la caisse Git: http://git-scm.com/

À la caisse Fossile: http://www.fossil-scm.org

Au départ Mercurial: https://www.mercurial-scm.org

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

le problème principal (mis à part la question évidente de la largeur de bande) est propriété .

, c'est-à-dire qu'il faut s'assurer que des sites (géographiques) différents ne fonctionnent pas sur le même élément que l'autre.

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

Pour répondre aux commentaires de cette réponse, vous voulez vraiment l'outil pour vous dire à qui appartient quoi, et alors communiquer (par téléphone, par messagerie instantanée ou par la poste) avec le site éloigné.

Si vous n'avez pas la propriété mécanisme... vous "communiquerez", mais souvent trop tard ;) (i.e.: après avoir fait du développement simultané sur un ensemble identique de fichiers dans la même branche. La validation peut être très salissant)

pour moi c'est une autre discussion sur un goût personnel et il 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 le réseau plus petit au - dessus-juste pour dire quelques-unes de mes propres raisons.

tout le monde ces jours-ci est sur le train de la façon dont les DVCSs 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 beaucoup de fichiers binaires (par exemple, des fichiers image ou FLAs) cela demande beaucoup d'espace et vous ne pouvez pas faire de diffs.

j'ai le sentiment que les DVCS mercuriels (et autres DVCS) sont plus sophistiqués que les DVCS centralisés. Par exemple, fusionner une branche dans Mercurial garde l'histoire complète de la branche alors que dans SVN vous devez aller dans le répertoire de la branche pour voir l'histoire.

un autre plus pour SCM distribué même dans le scénario solo developer est si vous, comme beaucoup d'entre nous là-bas, ont plus d'une machine sur laquelle vous travaillez.

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

1. un gain de temps, surtout avec les clés ssh
2. une façon de ventiler les différences entre les différents systèmes (par exemple: Red Hat vs Debian, BSD vs Linux, etc)

la réponse de W. Craig Trader résume la plupart de cela, cependant, je trouve que le style de travail personnel fait une énorme différence aussi bien. Là où je travaille actuellement, nous utilisons subversion comme Source unique, cependant, de nombreux développeurs utilisent git-svn sur leurs machines personnelles pour compenser les problèmes de flux de travail que nous avons (défaillance de la gestion, mais c'est une autre histoire). Dans tous les cas. il s'agit en fait d'équilibrer les ensembles de caractéristiques qui vous rendent le plus productif avec ce dont l'organisation a besoin (authentification centralisée, exemple.)

un système centralisé ne vous empêche pas nécessairement d'utiliser des branches séparées pour le développement. Il n'est pas nécessaire qu'il y ait une seule copie vraie de la base de code, plutôt différents développeurs ou équipes peuvent avoir différentes branches, les anciennes branches peuvent exister, etc.

ce que cela signifie généralement, c'est que le dépôt est géré centralement - mais c'est généralement un avantage dans une entreprise avec un département informatique compétent parce que cela signifie qu'il n'y a qu'un seul endroit pour sauvegarder et un seul endroit pour gérer le stockage dans.