Alle Versionskontrollsysteme haben ein gemeinsames, grundlegendes Problem zu lösen: Wie kann das System verschiedenen Benutzern erlauben, die Informationen zu teilen, aber gleichzeitig verhindern, dass die Benutzer sich gegenseitig auf die Füße treten? Es ist viel zu einfach für Benutzer, ungewollt Änderungen von anderen Benutzern zu überschreiben.
Stellen Sie sich folgende Szene vor: angenommen, wir haben zwei Mitarbeiter, Harry und Sally. Sie beide beschließen, dieselbe Datei gleichzeitig zu ändern. Wenn Harry seine Änderungen zuerst im Projektarchiv speichert, dann ist es möglich (ein paar Augenblicke später), dass Sally ungewollt diese Änderungen durch ihre eigenen überschreibt. Obwohl die Änderungen von Harry nicht verloren sind (das Versionskontrollsystem speichert alle Änderungen), werden Harrys Änderungen in der aktuellsten Version von Sally nicht vorhanden sein, weil Sally diese Änderungen nie gesehen hat. Harrys Änderungen sind also trotzdem verloren - oder zumindest fehlen diese in der aktuellsten Version. Dies ist definitiv eine Situation, die wir verhindern wollen!
Viele Versionskontrollsysteme nutzen ein Sperren-Ändern-Freigeben Modell, was eine sehr einfache Lösung ist. In einem solchen System kann jeweils nur eine einzige Person eine Datei ändern. Zuerst muss Harry die Datei sperren, bevor er mit dem Ändern beginnen kann. Sperren ist so ähnlich wie das Ausleihen eines Buchs aus der Bibliothek; wenn Harry die Datei gesperrt hat, dann kann Sally keine Änderungen an dieser Datei mehr vornehmen. Wenn sie es dennoch versucht, kriegt sie eine Fehlermeldung. Alles, was sie tun kann, ist die Datei lesen und zu warten, bis Harry die Datei wieder freigegeben hat (das Buch in die Bibliothek zurückgebracht hat). Danach kann Sally die Datei sperren und ihre Änderungen vornehmen.
Das Problem mit der Sperren-Ändern-Freigeben Lösung ist, dass diese zu restriktiv ist und oft zu einem Hindernis für die Benutzer wird:
Sperren kann administrative Probleme auslösen. Manchmal wird Harry eine Datei sperren und dann vergessen, diese wieder freizugeben. In der Zwischenzeit wartet Sally bis sie diese Datei ändern kann, aber durch die Sperre von Harry sind ihr die Hände gebunden. Und dann geht Harry in die Ferien. Nun braucht Sally einen Administrator, um die Sperre von Harry aufzuheben. Diese Situation führt zu unnötigen Verzögerungen und verschwendet Zeit.
Sperren kann zu unnötiger sequenzieller Arbeitsweise führen. Was, wenn Harry den Anfang einer Textdatei ändert und Sally das Ende dieser Textdatei ändern möchte? Diese Änderungen stören sich überhaupt nicht und könnten sehr einfach gleichzeitig ausgeführt werden, in der Annahme, dass diese Änderungen ohne Probleme zusammengeführt werden. Es ist in dieser Situation völlig unnötig zu warten, bis der eine mit der Arbeit fertig ist.
Sperren kann ein falsches Gefühl von Sicherheit erzeugen. Angenommen, Harry sperrt und ändert eine Datei A, während Sally eine Datei B gesperrt hat und ändert. Aber angenommen, diese beiden Dateien sind nicht unabhängig voneinander und die Änderungen an der einen Datei sind nicht kompatibel mit den Änderungen an der anderen Datei. Plötzlich funktionieren die Dateien A und B nicht mehr zusammen. Das Sperr-System konnte dieses Problem nicht verhindern - es spiegelte sogar eine falsche Sicherheit vor. Es ist einfach für Harry und Sally anzunehmen, dass durch das Sperren von Dateien jeder Änderungen sicher durchführen kann.
Subversion, CVS und andere Versionskontrollsysteme nutzen ein Kopieren-Ändern-Zusammenführen Modell als Alternative zur Sperrlösung. In diesem Modell hat jeder Benutzer eine persönliche Arbeitskopie des Projekts. Die Benutzer arbeiten dann parallel und ändern jeweils ihre persönliche Arbeitskopie. Schließlich werden diese privaten Arbeitskopien zu einer endgültigen Version zusammengeführt. Das Versionskontrollsystem hilft beim Zusammenführen, überlässt die endgültige Kontrolle aber dem Benutzer selbst.
Hier ein Beispiel. Angenommen, Harry und Sally haben jeder eine private Arbeitskopie von demselben Projekt. Sie arbeiten parallel und ändern dieselbe Datei A in ihren Arbeitskopien. Sally speichert ihre Änderungen zuerst im Projektarchiv. Wenn Harry nun dasselbe versucht, bekommt er eine Meldung vom Projektarchiv, dass seine Datei nicht aktuell ist. In anderen Worten, die Datei A wurde irgendwie im Projektarchiv verändert, seit er sie das letzte Mal aktualisiert hat. Also aktualisiert Harry seine Arbeitskopie mit dem Projektarchiv und führt die Änderungen im Projektarchiv mit seinen eigenen zusammen. Die Wahrscheinlichkeit, dass die Änderungen von Sally sich nicht mit seinen eigenen beißen, ist groß, und so kann Harry gleich danach die Datei im Projektarchiv speichern.
Aber was, wenn die Änderungen von Sally sich mit Harrys Änderungen tatsächlich überlappen? Was dann? Diese Situation wird ein Konflikt genannt und ist üblicherweise kein großes Problem. Wenn Harry in diesem Falle seine Arbeitskopie aktualisiert und die Änderungen von Sally mit den seinen zusammenführt, wird seine Kopie der Datei A als „In Konflikt“ markiert; er kann dann beide Versionen der Datei ansehen und manuell zwischen den Änderungen von Sally oder seinen eigenen wählen. Beachten Sie, dass Software solche Konflikte nicht selbst lösen kann; nur Menschen sind in der Lage, die Änderungen auch zu verstehen und die notwendigen intelligenten Entscheidungen (vielleicht durch ein Gespräch mit Sally) zu treffen.
Das Kopieren-Ändern-Zusammenführen Modell mag ein wenig chaotisch aussehen, aber in der Praxis bewährt es sich sehr gut. Benutzer können parallel arbeiten, müssen niemals aufeinander warten. Wenn sie an denselben Dateien arbeiten, stellt sich heraus, dass die meiste Zeit keine Konflikte auftreten. Und die Zeit, die benötigt wird, um einen der wirklich seltenen Konflikte zu lösen, ist viel kleiner als die Zeit, welche auf die Freigabe einer gesperrten Datei gewartet wird.
Schlussendlich hängt alles von einem einzigen kritischen Faktor ab: Kommunikation unter den Benutzern. Wenn die Benutzer nur schlecht miteinander kommunizieren, werden vermehrt Konflikte auftreten. Kein System kann Benutzer zur Kommunikation zwingen, und kein System kann logische Konflikte erkennen.
Es gibt eine Situation, in der das Sperren-Ändern-Freigeben Modell Vorteile bietet. Das ist bei Dateien der Fall, die sich nicht automatisch zusammenführen lassen. Wenn Ihr Projektarchiv zum Beispiel Grafiken enthält und zwei Personen gleichzeitig dieselbe Grafik ändern, kann Subversion nicht entscheiden, wie die Änderungen zusammengeführt werden. Entweder Harry oder Sally wird seine Änderungen verlieren.
Subversion verwendet standardmäßig das Kopieren-Ändern-Zusammenführen Modell, und in den meisten Fällen wird das alles sein, was Sie jemals benötigen werden. Mit der Einführung von Version 1.2 unterstützt Subversion auch das Sperren von Dateien, so dass Ihnen diese Möglichkeit ebenfalls zur Verfügung steht.