[linux-l] Verteilte Versionskontrollen zuerst lernen?

[olafBuddenhagen at gmx.net]

Hallo,

On Wed, Mar 17, 2010 at 07:45:02PM +0100, Volker Grabsch wrote:

> Auch das erst späte Aufkommen der DVCS zeigt, dass sie schwieriger zu
> implementieren sind als zentrale VCS.

Sind sie das wirklich?...

Wenn ich überlege, was bei einem zentralen VCS so passieren muss: Viele
Operationen wie Update, Merge, Checkout und Commit erfordern, den
lokalen Versionsstand, den Inhalt der ausgecheckten Dateien, und ein bis
zwei Versionsstände im Repository alle auf verschiedene Weise
miteinander zu vergleichen; und daraufhin (je nach Operation) den
Checkout, den lokalen Versionsstand, bzw. das Repository entsprechend
anzupassen.

Das Vergleichen von lokalem Versionsstand und Dateien ist Client-seitig
effizienter; das Vergleichen von Repository-Ständen ist auf dem Server
effizienter; Vergleich zwischen lokalem Versionsstand und Repository je
nach Situation mal so mal so; und Vergleich zwischen Dateien und
Repository mal direkt, und mal indirekt (erst Vergleichen mit dem
lokalen Versionsstand, gefolgt vom Vergleich mit dem Repository) -- in
beiden Fällen wieder Client-seitig oder Server-seitig. Dabei müssen
Versionsstände und/oder Dateiinhalte zum Vergleich gegebenenfalls
zwischen Client und Server ausgetauscht werden, ebenso wie die Resultate
des Vergleichs (Dateilisten und Diffs) zur weiteren Verwendung.

Damit das Ganze sicher ist, darf der Server bei Operationen, die
Änderungen am Repository verursachen, sich nicht auf den Client
verlassen -- er muss also eventuell vom Client generierte Diffs und
sonstige Daten nochmal gegen den eigenen Zustand validieren. Außerdem
muss bei allen Operationen frühzeitig entschieden werden, welche Dateien
einen Read-Lock bzw. einen Write-Lock brauchen -- generell alles zu
locken wäre bei einem zentralen System wahrscheinlich zu ineffizient, da
bei einem größeren Projekt ständig jemand auf das Repository zugreift,
und bei zu grobem Locking öfters Verzögerungen auftreten würden.

Verteiltes Systemdesign vom Feinsten also.

Eine dezentrale Versionsverwaltung wie Git scheint mir dagegen geradezu
simpel: Alle interessanten Operationen wie Commit, Merge etc. finden
lokal statt. Es ist also kein ausgefeiltes Locking nötig; keine
Validierung; keine ausgeklügelten Protokolle zum effizienten
Herausfinden der Unterschiede. Die einzige Remote-Operation ist der
Abgleich einer Referenz von einem Quellrepository zu einem
Zielrepository. Dazu müssen die Listen der jeweils referenzierten
Objekte verglichen werden; die im Zielrepository fehlenden Objekte
übertragen; und die Referenz aktualisiert.

Mehr braucht man für eine dezentrale Versionsverwaltung nicht.

Ich denke es hat gute Gründe, wieso Git nacht wenigen Wochen benutzbar
war (wenn auch die Oberfläche ziemlich "rau"), und nach wenigen Monaten
stabil; wohingegen Subversion Jahre dafür gebraucht hat -- und weitere
Jahre, um grundlegende Features wie Merge-Tracking zu bekommen...

Etwas abstrakter betrachtet, wird bei einer zentralen Versionsverwaltung
der Zustand verteilt zwischen Client und Server gehalten, und muss bei
den meisten Operationen auf komplexe Weise synchronisiert werden; wobei
die ständige Synchronisation mehr Optimierung erfordert, was das
Komplexitätsproblem noch verschlimmert. Bei dezentralen Systemen
hingegen erfolgt Synchronisation immer explizit, nie im Zuge anderer
Operationen.

Irgendwie kann ich mich des Eindrucks nicht erwehren, dass das auch aus
Anwendersicht konzeptuell eigentlich einfacher sein müsste...

Und nun frag mich nicht, wieso man nicht früher darauf gekommen ist,
dezentrale Versionsverwaltungen zu implementieren :-)

-Olaf-