XML Entwicklerhandbuch

5.2.1 Kurze Geschichte zur Versionskontrolle Test

Ich vermute, dass das Problem der Versionsverwaltung von Source Code Dateien seit Anbeginn der Programmierung existiert. So ist es nicht verwunderlich, dass die Lösungen hierzu immer weiter verfeinert werden. Zu jeder Epoche gibt es allerdings nur einen Platzhirschen, der allen Entwicklern gleichermassen heilig ist.

5.2.1.1 RCS

Bis zu den 90er Jahren war das in Unix Systeme integrierte,

RCS

beliebt. Jede Linux Distribution hat diese Lösung immer noch an Bord, und die Bedienung ist relativ einfach.

Bei RCS werden Änderungen an einzelnen Dateien in der jeweils zugeordneten Archivdatei verwaltet. Man kann dann die aktuelle Version in das Archiv einchecken und mit einer Logmeldung versehen.

Eine ausgecheckte Datei wird für andere Nutzer mit einem Lock versehen und gesperrt. Eine Check-In Sitzung sieht z.B. so aus:

$ ls -l
-rw-r--r--    1 Alex users          19 10. Oct 16:30 test.txt
$ cat test.txt
Hallo Welt!
$ ci -l test.txt
test.txt,v  <--  test.txt
enter description, terminated with single '.' or end of file:
NOTE: This is NOT the log message!
>> test check-in
>> .
initial revision: 1.1
done
$ ls -l
-rw-r--r--    1 alex users          19 10. Jan 14:25 test.txt
-r--r--r--    1 Alex users         218 10. Jan 14:25 test.txt,v
$ echo „bla bla blubb“ >> test.txt
$ ci -l test.txt
test.txt,v  <--  test.txt
new revision: 1.2; previous revision: 1.1
enter log message, terminated with single '.' or end of file:

Es gibt zusätzlich die Möglichkeit Branches anzulegen (über das Hinzufügen einer weiteren Stelle zur Versionsnummer).

Verschiedene Kopien können auch mittels einer Merge-Operation zusammengeführt werden. Ein Mehrbenutzerbetrieb ist also schon ansatzweise realisiert.

Praktisch ist RCS für mich nach-wie-vor, wenn ich eine elnzelne Datei trocken will, wie z.B. meinen Lebenslauf im ASCII-Text Format. Mittels Schlüsselwörter, wie $Author$ , $Date$ und $Log$ , lassen sich Metadaten zur Version automatisch in die Arbeitsdatei übernehmen.

RCS, das also den Mehrbenutzebetrieb nur über Absprachen bzgl. des Locking-Mechanimsu erlaubt, wurde in den 90er Jahren von CVS abgelöst.

5.2.1.2 CVS

Wie der Name schon sagt (Concurrent Versions System), erlaubt CVS ↗ den reibungslosen Mehrbenutzerbetrieb.

Im Gegensatz zu RCS werden Archivdateien nicht an ggf. verschiedenen frei definierbaren Orten gespeichert, sondern zentral in einem Repository.

Mittels grafischer Clients und der Integration in alle gängigen IDEs (Integrated Development Environment), erlaubt CVS bspw. ein komfortables grafisches Diffing, was den Review und die Übernahme von Änderungen eines anderen Programmierers, wesentlich erleichtert.

5.2.1.3 Subversion

CVS hatte einige Unzulänglichkeiten, was das Handling von Binärdaten und Verzeichnissen betraf, sowie einige Sicherheitsmängel ↗

Der Nachfolger von CVS ist Subversion ↗.

Was den Feature-Umgang angeht, sollte Subversion eigentlich für die meisten Anwendungsfälle in der Software-Entwicklung ausreichen, wäre da nicht die Open-Source Bewegung, die weltweit verteilt an Tausenden Projekten arbeitet.

So wurde das zentrale Repository, das eigentlich das Killer-Feature von CVS im Vergleich zu RCS war, nach der Jahrtausendwende mehr oder weniger über den Haufen geworfen.

Linus Toralds, der Erfinder von Linux, stellte GIT ↗ vor.

5.2.1.4 GIT

GIT ↗ weicht das Konzept des zentralen Repositories auf. Es gibt zwar meistens ein Repository, das zentral über das Netz erreichbar ist, jeder Entwickler arbeitet aber zusätzlich noch auf einer lokalen Kopie, die er regelmässig mit dem Haupt-Repository synchronisiert.

Ausserdem kann jedes Repository auch ge-„forkt“ werden, d.h. es wird von einer anderen Entwickler(-gruppe) kopiert, mit dem Ziel eine neue Variante der Software oder gar ein anderes Produkt zu erschaffen, was nach dem Open-Source Gedanken natürlich völlig legitim ist.