Vergleich zwischen zentralisierten und verteilten Versionskontrollsystemen [geschlossen]

Welche Vor- und Nachteile hat die Verwendung von DVCS ( Centralized versus Distributed Version Control Systems)? Haben Sie Probleme mit DVCS und wie haben Sie sich vor diesen Problemen geschützt? Halten Sie das Diskussionstool agnostisch und flammend auf ein Minimum.

Für diejenigen, die sich fragen, welche DVCS-Tools verfügbar sind, finden Sie hier eine Liste der bekanntesten Free / Open Source-DVCS:

• Git (geschrieben in C), das vom Linux-Kernel und Ruby on Rails verwendet wird .
• Mercurial (geschrieben in Python) wird von Mozilla und OpenJDK verwendet .
• Bazaar (geschrieben in Python) wird von Ubuntu-Entwicklern verwendet .
• Darcs (geschrieben in Haskell).

Von meiner Antwort auf eine andere Frage :

Verteilte Versionskontrollsysteme (DVCS) lösen andere Probleme als zentralisierte VCS. Der Vergleich ist wie der Vergleich von Hämmern und Schraubendrehern.

Zentralisierte VCS- Systeme wurden mit der Absicht entwickelt, dass es eine wahre Quelle gibt, die gesegnet und daher gut ist. Alle Entwickler arbeiten (Checkout) von dieser Quelle aus und fügen dann ihre Änderungen hinzu (festschreiben), die dann ähnlich gesegnet werden. Der einzige wirkliche Unterschied zwischen CVS, Subversion, ClearCase, Perforce, VisualSourceSafe und allen anderen CVCS besteht im Workflow, der Leistung und der Integration, die jedes Produkt bietet.

Verteilte VCS- Systeme wurden mit der Absicht entwickelt, dass ein Repository so gut wie jedes andere ist und dass das Zusammenführen von einem Repository zu einem anderen nur eine andere Form der Kommunikation darstellt. Jeder semantische Wert, welchem ​​Repository vertraut werden soll, wird von außen durch den Prozess und nicht durch die Software selbst auferlegt.

Die eigentliche Wahl zwischen der Verwendung des einen oder des anderen Typs ist organisatorisch. Wenn Ihr Projekt oder Ihre Organisation eine zentralisierte Steuerung wünscht, ist ein DVCS kein Starter. Wenn von Ihren Entwicklern erwartet wird, dass sie im ganzen Land / auf der ganzen Welt ohne sichere Breitbandverbindungen zu einem zentralen Repository arbeiten, ist DVCS wahrscheinlich Ihre Rettung. Wenn Sie beide brauchen, sind Sie fsck'd.

Für diejenigen, die glauben, dass verteilte Systeme keine autorisierenden Kopien zulassen, beachten Sie bitte, dass es viele Stellen gibt, an denen verteilte Systeme autorisierende Kopien haben. Das perfekte Beispiel ist wahrscheinlich der Kernelbaum von Linus. Sicher, viele Menschen haben ihre eigenen Bäume, aber fast alle fließen auf Linus 'Baum zu.

Trotzdem denke ich, dass verteilte SCMs nur für viele Entwickler nützlich sind, die verschiedene Dinge tun, aber kürzlich entschieden haben, dass alles, was ein zentrales Repository tun kann, ein verteiltes Repository besser kann.

Angenommen, Sie sind ein Einzelentwickler, der an Ihrem persönlichen Projekt arbeitet. Ein zentrales Repository ist möglicherweise eine naheliegende Wahl, berücksichtigen Sie jedoch dieses Szenario. Sie haben keinen Netzwerkzugriff (in einem Flugzeug, in einem Park usw.) und möchten an Ihrem Projekt arbeiten. Sie haben Ihre lokale Kopie, damit Sie gut arbeiten können, aber Sie möchten sich wirklich festlegen, weil Sie eine Funktion abgeschlossen haben und zu einer anderen wechseln möchten, oder Sie haben einen Fehler gefunden, den Sie beheben können, oder was auch immer. Der Punkt ist, dass Sie mit einem zentralisierten Repo entweder alle Änderungen zusammenführen und in einem nicht logischen Änderungssatz festschreiben oder sie später manuell aufteilen.

Mit einem verteilten Repo gehen Sie wie gewohnt weiter, legen fest, fahren fort, wenn Sie wieder über einen Netzzugriff verfügen, wechseln Sie zu Ihrem "One True Repo", und nichts hat sich geändert.

Ganz zu schweigen von der anderen schönen Sache bei verteilten Repos: Die vollständige Historie ist immer verfügbar. Sie müssen sich die Revisionsprotokolle ansehen, wenn Sie nicht im Netz sind? Sie müssen die Quelle mit Anmerkungen versehen, um zu sehen, wie ein Fehler verursacht wurde. Alles möglich mit verteilten Repos.

Bitte, bitte glauben Sie nicht, dass es bei Distributed vs Centralized um Eigentum oder maßgebliche Kopien oder ähnliches geht. Die verteilte Realität ist der nächste Schritt in der Entwicklung von SCMs.

Nicht wirklich ein Vergleich, aber hier sind, was große Projekte verwenden:

Zentralisierte VCSes

• Subversion

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

• CVS

  CVS

Verteilte VCSes

• git

  Linux-Kernel, KDE, Perl, Ruby on Rails, Android, Wein, Fedora, X.org, Mediawiki, Django, VLC, Mono, Gnom, Samba, CUPS, GnuPG, Emacs ELPA ...

• Quecksilber (hg)

  Mozilla und Mozdev, OpenJDK (Java), OpenSolaris, ALSA, NTFS-3G, Dovecot, MoinMoin, Köter, PETSc, Oktave, FEniCS, Eignung, Python, XEmacs, Xen, Vim, Xine ...

• bzr

  Emacs, Apt, Mailman, MySQL, Squid, ... werden auch innerhalb von Ubuntu beworben.

• Darcs

  ghc, ion, xmonad, ... beliebt in der Haskell Community.

• Fossil

  SQLite

W. Craig Trader sagte dies über DVCS und CVCS:

Wenn Sie beide brauchen, sind Sie fsck'd.

Ich würde nicht sagen, dass Sie fsck'd sind, wenn Sie beide verwenden. Praktisch Entwickler, die DVCS-Tools verwenden, versuchen normalerweise, ihre Änderungen (oder Pull-Anforderungen) an einem zentralen Ort (normalerweise in einem Release-Zweig in einem Release-Repository) zusammenzuführen. Es gibt einige Ironie bei Entwicklern, die DVCS verwenden, aber am Ende bleiben Sie bei einem zentralisierten Workflow. Sie können sich fragen, ob der verteilte Ansatz wirklich besser ist als der zentralisierte.

DVCS bietet gegenüber CVCS einige Vorteile:

• Die Vorstellung von eindeutig erkennbaren Commits macht das Senden von Patches zwischen Peers schmerzlos. Das heißt, Sie erstellen den Patch als Commit und teilen ihn mit anderen Entwicklern, die ihn benötigen. Später, wenn alle zusammengeführt werden möchten, wird dieses bestimmte Commit erkannt und kann zwischen Zweigen verglichen werden, wobei die Wahrscheinlichkeit eines Zusammenführungskonflikts geringer ist. Entwickler neigen dazu, Patches unabhängig vom verwendeten Versionierungstool per USB-Stick oder E-Mail aneinander zu senden. Leider registriert die Versionskontrolle im CVCS-Fall die Commits als separat und erkennt nicht, dass die Änderungen gleich sind, was zu einer höheren Wahrscheinlichkeit eines Zusammenführungskonflikts führt.

• Sie können lokale experimentelle Zweige haben (geklonte Repositorys können auch als Zweig betrachtet werden), die Sie anderen nicht zeigen müssen. Das bedeutet, dass sich Änderungen nicht auf Entwickler auswirken müssen, wenn Sie nichts vorgeschoben haben. Wenn Sie in einem CVCS noch eine wichtige Änderung haben, müssen Sie möglicherweise offline arbeiten, bis Sie diese behoben haben, und die Änderungen bis dahin festschreiben. Dieser Ansatz macht den Zweck der Verwendung der Versionierung als Sicherheitsnetz effektiv zunichte, ist jedoch in CVCS ein notwendiges Übel.

• In der heutigen Welt arbeiten Unternehmen normalerweise mit Offshore-Entwicklern zusammen (oder, wenn es noch besser ist, möchten sie von zu Hause aus arbeiten). Ein DVCS hilft bei solchen Projekten, da keine zuverlässige Netzwerkverbindung erforderlich ist, da jeder sein eigenes Repo hat.

… Und einige Nachteile, die normalerweise Problemumgehungen haben:

• Wer hat die letzte Revision? In einem CVCS hat der Trunk normalerweise die neueste Version, in einem DVCS ist dies jedoch möglicherweise nicht eindeutig ersichtlich. Die Problemumgehung basiert auf Verhaltensregeln, nach denen die Entwickler eines Projekts eine Vereinbarung treffen müssen, in der Repo ihre Arbeit zusammenführt.

• Pessimistische Sperren, dh eine Datei wird beim Auschecken gesperrt, sind aufgrund der Parallelität zwischen Repositorys in DVCS normalerweise nicht möglich. Der Grund für das Sperren von Dateien in der Versionskontrolle liegt darin, dass Entwickler Zusammenführungskonflikte vermeiden möchten. Das Sperren hat jedoch den Nachteil, dass die Entwicklung verlangsamt wird, da zwei Entwickler nicht gleichzeitig an demselben Code arbeiten können wie bei einem langen Transaktionsmodell, und es ist keine vollständige Garantie gegen Zusammenführungskonflikte. Die einzig vernünftige Möglichkeit, unabhängig von der Versionskontrolle, große Zusammenführungskonflikte zu bekämpfen, besteht darin, eine gute Codearchitektur (wie geringe Kopplung und hohe Kohäsion) zu haben und Ihre Arbeitsaufgaben so aufzuteilen, dass sie nur geringe Auswirkungen auf den Code haben (was leichter gesagt als getan ist). .

• In proprietären Projekten wäre es katastrophal, wenn das gesamte Repository öffentlich verfügbar wäre. Dies gilt umso mehr, wenn ein verärgerter oder böswilliger Programmierer ein geklontes Repository erhält. Quellcode-Leckagen sind für proprietäre Unternehmen ein schwerer Schmerz. DVCS macht dies ganz einfach, da Sie nur das Repository klonen müssen, während einige CM-Systeme (wie ClearCase) versuchen, diesen Zugriff einzuschränken. Wenn Sie jedoch meiner Meinung nach in Ihrer Unternehmenskultur eine ausreichende Funktionsstörung aufweisen, hilft Ihnen keine weltweite Versionskontrolle gegen Quellcode-Leckagen.

Bei meiner Suche nach dem richtigen SCM habe ich festgestellt, dass die folgenden Links eine große Hilfe sind:

1. Bessere SCM-Initiative: Vergleich . Vergleich von ca. 26 Versionskontrollsystemen.
2. Vergleich der Revisionskontrollsoftware . Wikipedia-Artikel zum Vergleich von 38 Versionskontrollsystemen zu Themen wie technischen Unterschieden, Funktionen, Benutzeroberflächen und mehr.
3. Verteilte Versionskontrollsysteme . Ein weiterer Vergleich, der sich jedoch hauptsächlich auf verteilte Systeme konzentrierte.

Bis zu einem gewissen Grad sind die beiden Schemata gleichwertig:

• Ein verteiltes VCS kann trivial ein zentrales emulieren, wenn Sie Ihre Änderungen nach jedem lokalen Commit einfach immer in ein bestimmtes Upstream-Repository übertragen.
• Ein zentrales VCS ist normalerweise nicht in der Lage, ein verteiltes VCS so natürlich zu emulieren, aber Sie können etwas sehr Ähnliches erhalten, wenn Sie etwas wie Quilt darüber verwenden. Quilt ist ein Tool zum Verwalten großer Patch-Sätze über einem Upstream-Projekt, wenn Sie nicht damit vertraut sind. Die Idee dabei ist, dass der DVCS-Commit-Befehl durch Erstellen eines neuen Patches implementiert wird und der Push-Befehl implementiert wird, indem jeder ausstehende Patch an das zentralisierte VCS übergeben und dann die Patch-Dateien verworfen werden. Das klingt etwas umständlich, funktioniert aber in der Praxis eigentlich ganz gut.

Trotzdem gibt es ein paar Dinge, die DVCSes traditionell sehr gut machen und aus denen die meisten zentralisierten VCSs ein bisschen einen Hasch machen. Das wichtigste davon ist wahrscheinlich die Verzweigung: Ein DVCS erleichtert das Verzweigen des Repositorys oder das Zusammenführen nicht mehr benötigter Verzweigungen und verfolgt dabei den Verlauf. Es gibt keinen besonderen Grund, warum ein zentrales System Probleme damit haben würde, aber historisch gesehen scheint es noch niemand richtig verstanden zu haben. Ob dies tatsächlich ein Problem für Sie ist, hängt davon ab, wie Sie die Entwicklung organisieren, aber für viele Menschen ist dies eine wichtige Überlegung.

Der andere mögliche Vorteil von DVCS ist, dass sie offline arbeiten. Ich hatte nie wirklich viel Sinn dafür; Ich entwickle meistens entweder im Büro (das Repository befindet sich also im lokalen Netzwerk) oder zu Hause (also gibt es ADSL). Wenn Sie auf Reisen viel an Laptops entwickeln, ist dies möglicherweise eine größere Überlegung für Sie.

Es gibt nicht sehr viele Fallstricke, die für DVCSes spezifisch sind. Es gibt eine etwas größere Tendenz für die Leute, still zu werden, weil man sich ohne Druck festlegen kann und es leicht ist, Dinge privat zu polieren, aber abgesehen davon hatten wir nicht sehr viele Probleme. Dies mag daran liegen, dass wir eine beträchtliche Anzahl von Open-Source-Entwicklern haben, die normalerweise mit dem Patch-Trading-Entwicklungsmodell vertraut sind, aber auch eingehende Closed-Source-Entwickler scheinen die Dinge relativ schnell zu erfassen.

Ich benutze Subversion seit vielen Jahren und war sehr zufrieden damit.

Dann begann das GIT-Buzz und ich musste es nur testen. Und für mich war das Hauptverkaufsargument die Verzweigung. Oh Junge. Jetzt muss ich mein Repository nicht mehr bereinigen, ein paar Versionen oder irgendwelche dummen Dinge zurückgehen, die ich bei der Verwendung von Subversion getan habe. Alles ist billig in DVDs. Ich habe zwar nur Fossil und Git ausprobiert, aber ich habe Perforce, CVs und Subversion verwendet und es sieht so aus, als hätten DVDs alle wirklich billige Verzweigungen und Markierungen. Sie müssen nicht mehr den gesamten Code auf eine Seite kopieren, sodass das Zusammenführen nur ein Kinderspiel ist.

Alle DVDs können mit einem zentralen Server eingerichtet werden. Sie erhalten jedoch unter anderem Folgendes

Sie können jede kleine Änderung einchecken, die Sie mögen, wie Linus sagt, wenn Sie mehr als einen Satz verwenden müssen, um zu beschreiben, was Sie gerade getan haben, tun Sie zu viel. Sie können den Code lokal verwenden, verzweigen, zusammenführen, klonen und testen, ohne dass jemand große Datenmengen herunterladen muss. Und Sie müssen nur die letzten Änderungen auf den zentralen Server übertragen.

Und Sie können ohne Netzwerk arbeiten.

Kurz gesagt, die Verwendung einer Versionskontrolle ist immer eine gute Sache. Die Verwendung von dvcs ist billiger (in KB und Bandbreite), und ich denke, die Verwendung macht mehr Spaß.

Zum Auschecken von Git: http://git-scm.com/
Zum Auschecken von Fossil: http://www.fossil-scm.org
Zum Auschecken von Mercurial: https://www.mercurial-scm.org

Jetzt kann ich nur dvcs-Systeme empfehlen, und Sie können problemlos einen zentralen Server verwenden

Verteilte VCS sind in vielerlei Hinsicht ansprechend, aber ein Nachteil, der für mein Unternehmen wichtig sein wird, ist das Problem der Verwaltung nicht zusammenführbarer Dateien (normalerweise binäre Dateien, z. B. Excel-Dokumente). Subversion behebt dies, indem es die Eigenschaft "svn: need-lock" unterstützt. Dies bedeutet, dass Sie eine Sperre für die nicht zusammenführbare Datei erhalten müssen, bevor Sie sie bearbeiten. Es funktioniert gut. Dieser Workflow erfordert jedoch ein zentrales Repository-Modell, das dem DVCS-Konzept widerspricht.

Wenn Sie also ein DVCS verwenden möchten, ist es nicht wirklich für die Verwaltung von Dateien geeignet, die nicht zusammengeführt werden können.

Das Hauptproblem (abgesehen von dem offensichtlichen Bandbreitenproblem) ist das Eigentum .

Das heißt, dass unterschiedliche (geografische) Standorte nicht mit demselben Element arbeiten wie der andere.

Im Idealfall kann das Tool einer Datei, einem Zweig oder sogar einem Repository den Besitz zuweisen.

Um die Kommentare dieser Antwort zu beantworten, möchten Sie, dass das Tool Ihnen wirklich sagt, wem was gehört, und dann (per Telefon, IM oder E-Mail) mit der entfernten Site kommuniziert.
Wenn Sie keinen Eigentumsmechanismus haben ... werden Sie "kommunizieren", aber oft zu spät;) (dh nach gleichzeitiger Entwicklung eines identischen Satzes von Dateien in demselben Zweig. Das Festschreiben kann chaotisch werden)

Für mich ist dies eine weitere Diskussion über einen persönlichen Geschmack und es ist ziemlich schwierig, wirklich objektiv zu sein. Ich persönlich bevorzuge Mercurial gegenüber den anderen DVCS. Ich schreibe gerne Hooks in derselben Sprache wie Mercurial und im kleineren Netzwerk-Overhead - um nur einige meiner eigenen Gründe zu nennen.

Alle sind heutzutage auf dem Vormarsch, wie überlegen DVCSs sind, aber Craigs Kommentar ist wichtig. In einem DVCS hat jede Person die gesamte Geschichte der Branche. Wenn Sie mit vielen Binärdateien arbeiten (z. B. Bilddateien oder FLAs), erfordert dies sehr viel Speicherplatz und Sie können keine Unterschiede machen.

Ich habe das Gefühl, dass Mercurial (und andere DVCS) ausgefeilter sind als die zentralisierten. Wenn Sie beispielsweise einen Zweig in Mercurial zusammenführen, bleibt der vollständige Verlauf des Zweigs erhalten, während Sie in SVN in das Zweigverzeichnis wechseln müssen, um den Verlauf anzuzeigen.

Ein weiteres Plus für verteiltes SCM auch in Einzelentwicklerszenarien ist, dass Sie, wie viele von uns, mehr als einen Computer haben, an dem Sie arbeiten.

Nehmen wir an, Sie haben eine Reihe allgemeiner Skripte. Wenn jeder Computer, auf dem Sie arbeiten, über einen Klon verfügt, können Sie Ihre Skripte bei Bedarf aktualisieren und ändern. Es gibt dir:

1. Eine Zeitersparnis, insbesondere mit SSH-Schlüsseln
2. eine Möglichkeit, Unterschiede zwischen verschiedenen Systemen zu verzweigen (z. B. Red Hat gegen Debian, BSD gegen Linux usw.)

Die Antwort von W. Craig Trader fasst das meiste zusammen, aber ich finde, dass der persönliche Arbeitsstil auch einen großen Unterschied macht. Wo ich derzeit arbeite, verwenden wir Subversion als unsere eine wahre Quelle. Viele Entwickler verwenden jedoch git-svn auf ihren persönlichen Computern, um Workflow-Probleme zu kompensieren (Fehler beim Management, aber das ist eine andere Geschichte). Auf jeden Fall. Es geht wirklich darum, die Funktionen, die Sie am produktivsten machen, mit den Anforderungen des Unternehmens in Einklang zu bringen (z. B. zentralisierte Authentifizierung).

Ein zentrales System hindert Sie nicht unbedingt daran, separate Zweige für die Entwicklung zu verwenden. Es muss keine einzige echte Kopie der Codebasis vorhanden sein, vielmehr können unterschiedliche Entwickler oder Teams unterschiedliche Zweige haben, ältere Zweige können existieren usw.

Dies bedeutet im Allgemeinen, dass das Repository zentral verwaltet wird. Dies ist jedoch im Allgemeinen ein Vorteil in einem Unternehmen mit einer kompetenten IT-Abteilung, da nur ein Ort zum Sichern und nur ein Ort zum Verwalten des Speichers vorhanden ist.