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, versehentlich Ä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, dass Sally (ein paar Augenblicke später) 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, dann kann er mit dem Ändern beginnen. 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, bekommt sie eine Fehlermeldung zu sehen. Alles, was sie tun kann, ist die Datei lesen und darauf zu warten, dass Harry die Datei wieder freigibt. Erst dann kann Sally die Datei sperren und ihre Änderungen vornehmen.
Das Problem an 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, sie 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ötig 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, unter 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 Sperrsystem konnte dieses Problem nicht verhindern - es spiegelte sogar eine falsche Sicherheit vor. Leicht wiegen sich Harry und Sally in falscher Sicherheit durch die Möglichkeit des Sperrens, was möglicherweise sogar verhindert, dass sie ihre miteinander unverträglichen Änderungen rechtzeitig diskutieren.
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 dem selben 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 anhand des Projektarchivs und führt die Änderungen aus dem Projektarchiv mit seinen eigenen zusammen. Die Chancen stehen gut, dass die Änderungen von Sally mit seinen verträglich sind, und so kann Harry die aktualisierte Datei nun meist ohne weiteres im Projektarchiv speichern.
Aber was, wenn die Änderungen von Sally sich mit Harrys Änderungen tatsächlich überschneiden? Was dann? Diese Situation wird 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 solche Konflikte nicht durch Software gelöst werden kann; nur Menschen sind in der Lage, die Änderungen auch zu verstehen und die notwendigen intelligenten Entscheidungen zu treffen. Erst wenn Harry von Hand den Konflikt aufgelöst hat (vielleicht durch ein Gespräch mit Sally!), kann er die aktualisierte Datei an das Projektarchiv zurück übertragen.
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 kürzer als die Zeit, die man auf die Freigabe einer gesperrten Datei warten müsste.
Letztlich hängt alles von einem einzigen kritischen Faktor ab: der 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.