Für die Fachschaftszeitung "Wurzelmännchen" an der TU Clausthal entstand der folgende Artikel im März 2007 - "Sofwareentwicklung unter Kontrolle":
Probleme
Die Entwicklung von Software im Team stellt alle Entwickler vor das Problem, dass jeder nur einen Teil der Software schreiben kann, denn schließlich soll gemeinsam eine umfangreiche und nicht von jedem eine eigene minimale Version einer Software implementiert werden. Ab einem gewissen Zeitpunkt benötigt jedoch jeder Entwickler des Teams Zugriff auf alle Quellcode-Teile, um daraus eine (hoffentlich) lauffähige Software zusammensetzen zu können. Das Herummailen von Quellcode und Teilen desselben ist in der Anfangsphase bei kleinen Projekten möglicherweise noch ein gangbarer Weg - bei größeren Software-Paketen mit vielen Quellcode-Dateien oder wenn es häufige Updates der einzelnen Komponenten gibt, raubt die Verwaltung des Codes jedoch viel Zeit, die dann nicht mehr für die eigentliche Entwicklung zur Verfügung steht.
Abhilfe
Abhilfe schafft hier offensichtlich primär die Einrichtung eines zentralen und von jedem Entwickler zugreifbaren Speicherplatzes. Betrachtet man den Prozess verteilter Programmierung noch etwas genauer, stellt sich jedoch heraus, dass ab und an die Notwendigkeit besteht, im Code eines anderen Entwicklers etwas zu ändern; möglicherweise arbeiten auch zwei Entwickler an derselben Datei. Derartige konkurrierende Zugriffe sind ohne eine Synchronisation oder das Sperren ("Locking") der Zugriffe auf eine Datei nicht handhabbar. Sperrungen von Dateien haben sich aber relativ häufig als Bumerang entpuppt, denn sie werden gern (besonders zu fortgeschrittener Zeit) nicht wieder gelöst, wodurch der Entwicklungsprozess verlangsamt oder wieder Zeit für die Administration des Speicherplatzes notwendig wird. Eine Synchronisation wiederum ist über das Internet schwer realisierbar.
Lösung
SVN, die Abkürzung für das (Sourcecode-)Versionierungssystem Subversion, stellt für die bisher genannten Probleme Lösungen bereit. Es basiert darauf, dass ein zentraler Speicherort, das so genannte "Repository", auf einem Server angelegt wird. In diesem legen alle Entwickler die von ihnen geschriebenen Sourcen ab. Das Bilden von Paketen (z.B. in Java) in Abhängigkeit von gemeinsam entwickelnden Gruppen ist dabei ebenso möglich wie das Anlegen eines Verzeichnisses für Dokumentationen und ähnliches. Für Dokumentationen sollten Klartext-Formate wie XML oder TeX bei der Verwaltung durch SVN binären Formaten vorgezogen werden, da SVN intern lediglich die Änderungen der (Klartext-)Daten zwischen den Versionen speichert, was unter anderem zu einem geringeren Speicherplatzbedarf führt.
Die Arbeit mit SVN
Da nicht dauerhaft direkt auf dem Repository gearbeitet werden kann (sonst gäbe es das Problem des gleichzeitigen Zugriffs ja doch wieder), arbeiten die Entwickler auf Kopien des Repositories, den so genannten "Workspaces". Durch ein Herunterladen beziehungsweise "Auschecken" des Codes aus dem Repository auf die eigene Festplatte besteht eine komplette Kopie der zentral vorhandenen Quellen aller Entwickler. Damit ist die Programmierung ohne ständig notwendigen Zugriff auf das Repository möglich; die eigenen Änderungen werden nach sinnvoller Zeit an selbiges durch eine "Commit"-Aktion übertragen und dort abgelegt. Sehr vorteilhaft ist hier wiederum, dass ein Entwickler Fehler im Zusammenspiel mit dem Code der anderen Komponenten lokal beheben kann, bevor er seine Neuerungen den anderen Entwicklern zur Verfügung stellt. Bei der Übermittlung von Änderungen an SVN ist die Angabe eines kurzen Kommentars wichtig und sinnvoll, um einen groben Überblick über die getätigten Änderungen zu hinterlegen.
Besteht ein Repository, erledigt Subversion die wesentlichen Verwaltungstätigkeiten. So ermöglicht es "gleichzeitiges" Bearbeiten einer Datei durch mehrere Entwickler. Dies geschieht insbesondere durch das automatische Zusammenführen sich nicht überschneidender Änderungen einer einzigen Datei beim Commit (der Prozess nennt sich "Merging"). Kommt es doch einmal zu einem Konflikt, so kann das Merging in der Regel mit bestehenden Werkzeugen problemlos per Hand durchgeführt werden. Im Repository sind weiterhin alle Änderungen einer Datei nachvollziehbar, da alle Versionen (die Versionsnummer wird bei jeder Änderung der Datei inkrementiert) ihrerselbst archiviert werden. Dieses Vorgehen hat unter anderem den Vorteil, dass ein Fehler, der erst ab einer gewissen Dateiversion auftritt, relativ schnell auffindbar und temporär dadurch zu umgehen ist, dass eine ältere Version der Datei genutzt wird. Jede Änderung kann darüber hinaus einem Entwickler zugeordnet werden, so dass bei Problemen mit einer Änderung dieser direkt kontaktiert werden kann. Für das Auslesen entsprechender Informationen bestehende SVN-Befehle sind "log" (zeigt alle archivierten Versionen der Datei mit den wesentlichen Daten wie Revision, Autor etc. an) und "blame" (Anzeige der tatsächlichen Änderungen im Code einschließlich Autor und Revision).
Etiketten und Äste
Für die Versionierung bietet SVN neben der internen Nummerierung auch spezielle Marken, die so genannten "Tags". Die zum Zeitpunkt des Markierens aktuelle Version aller Dateien im Repository wird dabei in einem übergeordneten und von Änderungen der Dateien unabhängigen Tag zusammengefasst, wodurch auf den so markierten Stand dauerhaft einfach zugegriffen werden kann. Vorteil des Taggings ist dabei, dass ein Tag nicht nur eine Nummer sondern auch Informationsträger ist; ein Tag könnte beispielsweise "Beta4" oder "RC1" heißen, was eine wesentlich intuitivere Benennung darstellen sollte als eine einfache "142".
Nutzt man ersteinmal das Tagging, kommt man dauerhaft an einem weiteren Element von SVN kaum vorbei: Dem so genannten "Branching". Im Zuge der längerfristigen Entwicklung von Software entstehen in der Regel stabile Versionen mit einer begrenzten Anzahl an Funktionen (im Sinne der vom Anwender nutzbaren Features) auf der einen und instabile (Beta-)Versionen mit einem größeren Funktionsumfang oder einer neuen Codebasis auf der anderen Seite. Solche Unterschiede werden häufig durch verschiedene Nummerierungen dargestellt; als prominentes Beispiel können hier die Versionen 1.5 und 2.0 des Firefox-Browsers betrachtet werden. Da neue Features einer Software häufig auf Teilen der vorherigen Version basieren, ist die Speicherung beider Zweige in einem SVN-Repository sinnvoll. Dieses wird durch SVN und das Branching auch ermöglicht: Durch Anlegen einer solchen Verzweigung ist die Programmierung von Sicherheits- und Bugfixes auf der alten Version parallel zur Integration neuer Funktionen für die neue Version innerhalb desselben Respositories ganz einfach handhabbar.
Mein Fazit
Subversion stellt für die Entwicklung von Software nicht nur aber insbesondere in Gruppen ein umfangreiches und nach einer kurzen Eingewöhnung sehr einfach bedienbares Werkzeug dar, das wesentliche Verwaltungstätigkeiten übernimmt und damit der eigentlichen Entwicklung mehr Zeit einbringt. Dieser Artikel erhebt keinesfalls den Anspruch, die Versionsverwaltung rundum umfassend und abschließend zu erklären sondern soll einen Einstieg in die Materie anregen. Entsprechend ist bei gegebenem Interesse der Besuch der zugehörigen Webseiten http://subversion.tigris.org (SVN selber) sowie http://svnbook.red-bean.com (eine Referenz) angeraten.