Versionsverwaltung (englisch „Source Code Management“ oder „Revision control“) ist für Software-Entwicklung, aber zunehmend auch für andere Bereiche in der Informatik nicht nur nützlich, sondern geradezu unentbehrlich. Vielleicht das erste derartige System war SCCS, das durch das von Walter Tichy entwickelte RCS ersetzte aber fast SCCS vollständig. RCS mag noch eine gewisse Existenzberechtigung haben, wenn man lokal einzelne Dateien versionieren will und dies schon seit langer Zeit mit RCS macht, aber die Einschränkungen waren doch erheblich: RCS funktionierte nur innerhalb des Dateisystems. Mittels NFS oder SMB kann man zwar gemeinsame Dateisysteme mounten oder als Netzwerklaufwerke verbinden, aber die Restriktion war letztlich störend und unnötig. Außerdem konnte man nur einzelne Dateien, nicht aber Verzeichnisse und Gruppen von Dateien verwalten. Gewisse Wrapper wie z.B. SNiFF+ oder MKS versuchten diese Einschränkungen teilweise zu umgehen, letztlich war aber die auf der Basis von RCS entstandene Neuentwicklung CVS die bessere Lösung. Auch wenn CVS heute längst obsolet ist. Etwa gleichzeitig kam ClearCase auf, ein ebenfalls heute nicht mehr empfehlenswertes System. Sowohl CVS als auch ClearCase haben aber Konzepte eingeführt oder populär gemacht oder auch nur getestet, die man für heutige Versionsverwaltungssysteme verwendet oder auch für überflüssig erkannt hat, man konnte auch wieder aus den Schwächen dieser Systeme lernen. CVS hat keine Konsistenz sichergestellt, das heißt, dass bei einer Änderung, die mehrere Dateien umfasst, jemand, der zeitnah mit dem Einfügen der Änderungen ins CVS daraus liest, unter Umständen eine nicht lauffähige Mischung aus alt und neu erhält. Das Umbenennen und Verschieben von Verzeichnissen und Dateien, insbesondere in der Java-Welt als „Refactoring“ bekannt und populär, wird sehr schlecht unterstützt bzw. durch das Löschen und Neuanlegen behelfsmäßig abgebildet. Und binär-Dateien werden schlecht unterstützt. ClearCase hat zusätzlich noch weitere Nachteile: Es ist sehr langsam, unzuverlässig und braucht einen hohen Administrationsaufwand. Außerdem waren die Lizenzen einmal sehr teuer, was aber heute egal sein sollte, da es keinen vernünftigen Grund gibt, neue Projekte mit ClearCase anzufangen und bei vorhandenen Projekten die Lizenzierung gelöst und bezahlt sein sollte. Immerhin macht einem der Lizenz-Manager noch zusätzlich gelegentlich das Leben schwer. MS-VisualSourceSafe habe ich eine zeitlang sporadisch benutzt und es war etwa zwischen RCS und CVS anzusiedeln, soll aber durch ein besseres TFS ersetzt worden sein, das ich nicht kenne.
Nun kommen wir zu den Systemen, die man heute noch benutzen kann, auch ohne durch Altlasten dazu gezwungen zu sein. Ein Ersatz für CVS war SubVersion, das die wesentlichen Schwächen von CVS behebt. Wenn auch durchaus Linus‘ Torvalds Kommentar dazu bedenkenswert ist: „SubVersion is CVS done right, but CVS can’t be done right“ oder so ähnlich, z.B. in diesem Tech Talk von 2007. Git hat ein funktionierendes verteiltes Repository gebracht. Das bedeutet, dass man sogar ohne Netzwerkverbindung noch mit dem immer vorhandenen lokalen Repository arbeiten kann, dass „Backups“ einfach durch die Vielzahl der Repositories „passieren“, sogar ohne dass man sie explizit durchführt (was man natürlich trotzdem tun sollte) und dass die parallele Arbeit von sehr vielen Entwicklern an verschiedenen Orten erleichtert wird. Ein Problem ist dabei sicher die Benennung von Versionen, wenn man nicht von einem zentralen „Zähler“ abhängig sein will. Für Google mag es sinnvoll sein, in vielen größeren Rechenzentren eine Atomuhr aufzustellen, so dass man recht zuverlässige Zeitstempel hat, aber mein Laptop ist offline doch schon einmal etwas ungenau mit seiner Uhrzeit. Git verwendet eine SHA1-Prüfsumme von 128 Bit Länge, die ihren Zweck einigermaßen zuverlässig erfüllen, weil es schwierig ist, eine Datei zu konstruieren, die denselben Prüfsummenwert liefert, selbst wenn man es gezielt versucht. Mercurial und vielleicht auch Bazaar sollen ähnliche Features wie git bieten und es ist teilweise eher eine Geschmacksfrage, welches dieser Systeme man verwendet. Vielleicht hat git einen kleinen Vorteil wegen der hohen Verbreitung und wegen github.
Kurze Zusammenfassung: Subversion ist nicht schlecht, man kann das für kleine Projekte nehmen oder es beibehalten, wenn es in vorhandenen Projekten eingesetzt wird. Aber für neue Projekte oder für Projekte, die heute auf CVS, ClearCase oder anderen veralteten Versionsverwaltungssystemen entwickelt werden, empfehle ich, git, mercurial oder eventuell bazaar einmal genauer anzuschauen und auf eines dieser Systeme zu wechseln. Grundsätzlich sind die sicher alle gut, aber man kann sagen, dass sich git durchgesetzt hat, weshalb es wohl die beste Wahl darstellen dürfte, weil es alle kennen, weil es dafür Infrastruktur gibt u.s.w..
Auch wenn diese Versionsverwaltungssysteme primär für Software-Quelltexte gemacht sind, kann man sie auch für andere Dateien einsetzen. Allerdings gibt es auch Software, die implizit eine Versionsverwaltung enthält, zum Beispiel Wikis wie MediaWiki oder ECM-Systeme oder Dokumentenmanagementsysteme wie z.B. OpenText oder SharePoint, wo die Versionsverwaltung nur einen Teil der angebotenen Funktionalität ausmacht. Für die Details würde ich Experten für ECM-Systeme fragen…
Es wird noch interessant, ob uns die Zukunft noch neue interessante Versionskontrollsysteme mit neuen Konzepten bringt oder ob die Generation von Git uns jetzt für eine sehr lange Zeit begleiten wird.
