it-swarm.com.de

Vergleich zwischen zentralen und verteilten Versionskontrollsystemen

Was sind die Vor- und Nachteile bei der Verwendung von zentralisierten versus verteilten Versionskontrollsystemen? (DVCS)? Sind Sie auf Probleme mit DVCS gestoßen 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:

76
Spoike

Von meine Antwort zu einem anderen Frage :

Verteilte Versionskontrollsysteme (DVCS) lösen andere Probleme als zentralisierte VCS. Ein Vergleich ist wie ein Vergleich von Hammer und Schraubenzieher.

Centralized VCS Systeme werden mit der Absicht entwickelt, dass es eine wahre Quelle gibt, die gesegnet und daher gut ist. Alle Entwickler arbeiten von dieser Quelle aus (checkout) und fügen dann ihre Änderungen hinzu (commit), die dann auf ähnliche Weise 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.

Distributed VCS Systeme sind mit der Absicht konzipiert, dass ein Repository so gut wie jedes andere ist und dass das Zusammenführen von einem Repository zum anderen nur eine andere Form der Kommunikation darstellt. Jeder semantische Wert, auf den sich das Repository verlassen soll, wird von außen prozessbedingt und nicht von der Software selbst auferlegt.

Die wirkliche Wahl zwischen der Verwendung des einen oder anderen Typs ist organisatorisch - wenn Ihr Projekt oder Ihre Organisation eine zentrale Steuerung wünscht, ist ein DVCS ein Nichtstarter. Wenn von Ihren Entwicklern erwartet wird, dass sie landesweit und weltweit ohne sichere Breitbandverbindungen zu einem zentralen Repository arbeiten, ist DVCS wahrscheinlich Ihre Rettung. Wenn du beides brauchst, bist du fsck'd.

56
Craig Trader

Wenn Sie der Meinung sind, dass verteilte Systeme keine autorisierenden Kopien zulassen, beachten Sie, dass es viele Stellen gibt, an denen verteilte Systeme autorisierende Kopien haben. Das perfekte Beispiel hierfür ist wahrscheinlich der Linus-Kernelbaum. Sicher, viele Menschen haben ihre eigenen Bäume, aber fast alle fließen in Richtung Linus 'Baum.

Das heißt, ich habe immer gedacht, dass verteilte SCMs nur für viele Entwickler nützlich sind, die verschiedene Dinge tun, aber vor kurzem haben wir entschieden, dass alles, was ein zentrales Repository kann, ein verteiltes besser kann.

Angenommen, Sie sind ein Einzelentwickler, der an Ihrem eigenen persönlichen Projekt arbeitet. Ein zentrales Repository könnte eine naheliegende Wahl sein, aber bedenken Sie dieses Szenario. Sie haben keinen Netzwerkzugriff (im Flugzeug, in einem Park usw.) und möchten an Ihrem Projekt arbeiten. Sie haben Ihre lokale Kopie, damit Sie einwandfrei arbeiten können, aber Sie möchten wirklich ein Commit durchführen, weil Sie eine Funktion abgeschlossen haben und zu einer anderen wechseln möchten, oder Sie haben einen Fehler gefunden, der behoben werden muss, oder was auch immer. Der Punkt ist, dass Sie bei einem zentralen Repo entweder alle Änderungen zusammenfassen und in einem nicht logischen Changeset festschreiben oder sie später manuell aufteilen.

Mit einem verteilten Repo gehen Sie wie gewohnt in Betrieb, legen fest, machen weiter, wenn Sie wieder Netzzugriff haben, drücken Sie auf Ihr "ein echtes Repo" und es ändert sich nichts.

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

Bitte, bitte, glauben Sie nicht, dass es sich bei "Distributed vs Centralized" um Eigentum oder autorisierende Kopien oder Ähnliches handelt. Die Realität verteilt ist der nächste Schritt in der Entwicklung von SCM.

46
manicmethod

Kein wirklicher Vergleich, aber hier sind die wichtigsten Projekte:

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 .. .

  • Mercurial (hg)

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

  • bzr

    Emacs, Apt, Mailman, MySQL, Squid, ... werden auch in Ubuntu beworben.

  • darcs

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

  • Fossil

    SQLite

26
sastanin

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

Wenn du beides brauchst, bist du fsck'd.

Ich würde nicht sagen, dass Sie fsck'd sind, wenn Sie beide verwenden. In der Praxis versuchen Entwickler, die DVCS-Tools verwenden, ihre Änderungen zusammenzuführen (oder Pull-Anforderungen zu senden), und zwar an einen zentralen Speicherort (normalerweise an einen Release-Zweig in einem Release-Repository). Bei Entwicklern, die DVCS verwenden, gibt es eine gewisse Ironie, aber letztendlich stellt sich die Frage, ob der verteilte Ansatz wirklich besser ist als der zentralisierte.

DVCS bietet einige Vorteile gegenüber CVCS:

  • Das Konzept eindeutig erkennbarer 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, da das Risiko von Zusammenführungskonflikten geringer ist. Entwickler neigen dazu, sich Patches per USB-Stick oder E-Mail zu senden, unabhängig davon, welches Versionierungstool Sie verwenden. Leider werden die Commits im CVCS-Fall von der Versionskontrolle als getrennt registriert, und es wird nicht erkannt, dass die Änderungen identisch sind, was zu einer höheren Wahrscheinlichkeit von Zusammenführungskonflikten führt.

  • Sie können lokale experimentelle Verzweigungen haben (geklonte Repositorys können auch als Verzweigung betrachtet werden), die Sie anderen nicht zeigen müssen. Das bedeutet, dass Änderungen keine Auswirkungen auf Entwickler haben müssen, wenn Sie keine Upstreams durchgeführt haben. In einem CVCS müssen Sie möglicherweise offline arbeiten, bis Sie das Problem behoben haben und die Änderungen bis dahin festschreiben. Mit diesem Ansatz wird der Zweck der Verwendung der Versionierung als Sicherheitsnetz zwar effektiv zunichte gemacht, es ist jedoch ein notwendiges Übel in CVCS.

  • In der heutigen Welt arbeiten Unternehmen normalerweise mit Offshore-Entwicklern (oder, wenn noch besser, von zu Hause aus). Ein DVCS hilft bei solchen Projekten, da keine zuverlässige Netzwerkverbindung mehr erforderlich ist, da jeder über ein eigenes Repo verfügt.

… Und einige Nachteile, die normalerweise Abhilfemaßnahmen haben:

  • Wer hat die neueste Version? In einem CVCS hat der Trunk normalerweise die neueste Version, aber in einem DVCS ist dies möglicherweise nicht klar ersichtlich. Die Problemumgehung verwendet Verhaltensregeln, mit denen sich die Entwickler in einem Projekt darauf einigen müssen, gegen welche Repo ihre Arbeit zusammengeführt werden soll.

  • Pessimistische Sperren, d. H. Eine Datei wird beim Auschecken gesperrt, sind normalerweise nicht möglich, da in DVCS möglicherweise mehrere Repositorys gleichzeitig vorhanden sind. Der Grund, warum die Dateisperrung in der Versionskontrolle vorhanden ist, besteht 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 niedrige Kopplung, hohe Kohäsion) zu haben und Ihre Arbeitsaufgaben so zu unterteilen, 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. Umso mehr, wenn ein verärgerter oder böswilliger Programmierer ein geklontes Repository erhält. Source Code Leakage ist ein schwerwiegender Schmerz für proprietäre Unternehmen. DVCS vereinfacht dies, 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 genügend Dysfunktionalität aufweisen, hilft Ihnen keine Versionskontrolle auf der Welt gegen Quellcodeverluste.

20
Spoike

Bei der Suche nach dem richtigen SCM habe ich folgende Links als hilfreich empfunden:

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

In gewissem Maße sind die beiden Schemata gleichwertig:

  • Ein verteiltes VCS kann ein zentrales trivial emulieren, wenn Sie Ihre Änderungen nach jedem lokalen Commit nur immer in ein bestimmtes Upstream-Repository übertragen.
  • Ein zentrales VCS kann ein verteiltes normalerweise nicht so natürlich emulieren, aber Sie können etwas sehr Ähnliches erhalten, wenn Sie etwas wie quilt darüber verwenden. Wenn Sie mit Quilt nicht vertraut sind, ist es ein Tool zum Verwalten einer großen Anzahl von Patches über ein vorgelagertes Projekt. Die Idee dabei ist, dass der DVCS-Festschreibungsbefehl durch Erstellen eines neuen Patches implementiert wird, und der Push-Befehl durch Festschreiben jedes ausstehenden Patches an das zentralisierte VCS und anschließendes Verwerfen der Patch-Dateien. Das klingt etwas umständlich, funktioniert aber in der Praxis recht gut.

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

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

Tatsächlich gibt es nicht sehr viele Fallstricke, die für DVCS spezifisch sind. Es gibt eine etwas größere Tendenz, dass die Leute leise werden, weil man ohne Druck etwas unternehmen kann und es leicht ist, Dinge privat zu polieren, aber ansonsten 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-Modell der Entwicklung vertraut sind, aber auch eingehende Closed-Source-Entwickler scheinen die Dinge einigermaßen schnell in den Griff zu bekommen.

8
Steven Smith

Verteilte VCS sind in vielerlei Hinsicht ansprechend, aber ein Nachteil, der für mein Unternehmen von Bedeutung sein wird, ist das Problem der Verwaltung nicht zusammenführbarer Dateien (normalerweise Binärdateien, z. B. Excel-Dokumente). Subversion unterstützt hierfür die Eigenschaft "svn: needs-lock". Dies bedeutet, dass Sie eine Sperre für die nicht zusammenführbare Datei erhalten müssen, bevor Sie sie bearbeiten können. Es funktioniert gut. Für diesen Workflow ist jedoch ein zentrales Repository-Modell erforderlich, das dem DVCS-Konzept widerspricht.

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

4
Craig McQueen

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

Dann begann das GIT-Summen und ich musste es nur noch 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, die ich bei der Verwendung von Subversion getan habe, wiederherstellen. Bei dvcs ist alles billig. Ich habe zwar nur Fossil und Git ausprobiert, aber ich habe Perforce, CVS und Subversion verwendet und es sieht so aus, als hätten alle DVDs wirklich billige Verzweigungen und Markierungen. Es muss nicht mehr der gesamte Code auf eine Seite kopiert werden und das Zusammenführen ist daher ein Kinderspiel.

Jeder dvcs kann mit einem zentralen Server eingerichtet werden, aber Sie erhalten unter anderem

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 verwenden, verzweigen, zusammenführen, klonen und lokal 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 macht meiner Meinung nach mehr Spaß.

So checken Sie Git aus: http://git-scm.com/
Fossil auschecken: http://www.Fossil-scm.org
Zur Kasse Mercurial: https://www.Mercurial-scm.org

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

4
Trausti Thor

Das Hauptproblem (abgesehen vom offensichtlichen Bandbreitenproblem) ist Eigentumsrecht.

Das soll sicher sein, dass unterschiedliche (geografische) Standorte nicht am selben Element arbeiten wie die anderen.

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 wirklich, dass das Tool Ihnen sagt, wem was gehört, und dann mit (per Telefon, IM oder E-Mail) kommuniziert die entfernte Stelle.
Wenn Sie keinen Eigentumsmechanismus haben ... werden Sie "kommunizieren", aber oft zu spät;) (dh nachdem Sie eine identische Gruppe von Dateien in demselben Zweig gleichzeitig entwickelt haben. Das Festschreiben kann chaotisch werden )

3
VonC

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 Hooks gerne in der gleichen Sprache wie Mercurial und der kleinere Netzwerk-Overhead - um nur einige meiner eigenen Gründe zu nennen.

3
unexist

Alle sind heutzutage gespannt, 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), ist sehr viel Speicherplatz erforderlich, und Sie können keine Diffs ausführen.

2
elmonty

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

1
Roman Plášil

Ein weiteres Plus für verteiltes SCM, selbst im Solo-Entwickler-Szenario, ist, dass Sie, wie viele von uns, mehr als eine Maschine haben, auf der 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, vor allem mit ssh tasten
  2. eine Möglichkeit, Unterschiede zwischen verschiedenen Systemen zu verzweigen (z. B. Red Hat gegen Debian, BSD gegen Linux usw.)
1
user125959

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 verschiedene Entwickler oder Teams unterschiedliche Zweige haben, es können ältere Zweige existieren usw.

Im Allgemeinen bedeutet dies, dass das Repository zentral verwaltet wird. Dies ist jedoch in der Regel 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.

0
MarkR

Die Antwort von W. Craig Trader fasst das meiste zusammen, aber ich finde, dass der persönliche Arbeitsstil ebenfalls einen großen Unterschied macht. Wo ich derzeit arbeite, verwenden wir Subversion als unsere einzig wahre Quelle. Viele Entwickler verwenden jedoch git-svn auf ihren PCs, um das von uns verursachte Workflow-Problem zu kompensieren (Managementfehler, aber das ist eine andere Geschichte). Auf jeden Fall. Es geht wirklich darum, das Gleichgewicht zwischen den Features zu finden, die Sie am produktivsten machen, und den Anforderungen des Unternehmens (z. B. zentralisierte Authentifizierung).

0
Mark Kegel