Subversion Client

Installation

Unter Ubuntu-Linux

sudo apt-get install subversion

Unter Windows

Download unter http://downloads.open.collab.net/collabnet-subversion.html.

Initial checkout

Bevor mit Repositoryinhalten gearbeitet werden kann, muss zunächst eine lokale Kopie erstellt werden. In dieser sogenannten Sandbox kann der Entwickler seine Änderungen vornehmen, ohne dabei Parallelentwicklungen von Mitarbeitern zu stören. Dabei wird ein verstecktes Verzeichnis Namens .svn erstellt - dieses niemals von Hand editieren (es sei denn Du weißt genau was Du tust). Die Beispielkommandozeile läd den Hauptentwicklungsstamm vom <Pfad> in das aktuelle Arbeitsverzeichnis. (Das Unterverzeichnis trunk muss nicht zwingend auf dem Server vorhanden sein, warum und wieso diese Konvention Sinn ergibt, erkläre ich später im Anhang.)

svn checkout svn://<Servername>/<Pfad>/trunk

Commit

Sind alle nötigen Änderungen vollzogen oder beendet man seinen Arbeitstag und möchte man seine Änderungen den anderen Entwicklern bekannt machen, so muss der Inhalt der Sandbox wieder ins Repository hochgeladen werden. Da man dieses Kommando im Verzeichnis der Sandbox aus ausführen sollte, weiss der Client aufgrund der Daten im .svn Verzeichnis, welche Benutzer- und Repositoryeinstellungen fuer den Upload nötig sind.

svn commit -m "Dies ist mein Kommentar zu meinen Aenderungen"Jede Änderung sollte mit einem aussagekräftigen Kommentar abgeschickt werden. Dieses Hilft den Kollegen Änderungen schneller nachzuvollziehen oder aber auch bei einem Rücksprung auf eine ältere Version den Einstiegspunkt schneller zu finden. Diese kann man entweder mittels -m “Kommentar” bzw. –message “Kommentar” an die Commit-Befehlszeile heranhängt - tut man dieses nicht, wird der lokal bevorzugt eingestellte Editor gestartet in dem man den Kommentar eingeben kann.

Dateien hinzufügen

Nur das bloße existieren durch Anlegen einer Datei in einer Sandbox sorgt nicht dafür, dass diese beim nächsten commit mit hochgeladen wird. Diese muss zunächst manuell bekannt gemacht werden. Dieses geschieht mit

svn add <Dateiname>

Update

Will man seine lokale Kopie - also die Sandbox - auf den aktuellsten Stand bringen - führt man im selbigen Verzeichnis das update Kommendo auf. Auch bei diesem Befehl, wie bei allen anderen repository-abhängigen Befehlen erkennt der SVN Client die Einstellungen über das .svn Verzeichnis.

svn update

Merging

Haben zwei commits zueinander einen Inhaltskonflikt ausgelöst, muss der 2. Entwickler vor dem abschliessen seines commits die 2 Dateien von Hand bearbeiten um schliesslich eine gemischte Version hochladen zu können.

Tatsächlich macht Subversion den 2. Entwickler bei dem Versuch ein commit auszuführen darauf aufmerksam, dass er zunächst ein update ausführen muss.

Normalerweise versucht Subversion das merging (initiiert durch das update) automatisch vorzunehmen. Dieses klappt in der Regel bei Textdateien, wo nur an auffällig verschiedenen Stellen Änderungen vorgenommen wurden. Wurde jedoch eine Datei von mehreren an der selben Stelle bearbeitet, legt der Client bei dem verantwortlichen Entwickler 3 neue Dateien an.

Die lokale Datei (also “nur” <Dateiname>) wurde mit zusätzlichen Markern versehen, an den Stellen, wo Subversion einen Konflikt festgestellt hat. Diese Datei beinhaltet also die lokalen Aenderungen, als auch die Änderungen die bereits im Subversion commited wurden. Nun muss der Konflikt in der Datei filename von Hand gelöst werden.Hat man den Konflikt gelöst muss man bevor man ein weiteres mal svn commit aufruft Subversion bekannt machen, dass man den Konflikt auch tatsächlich gelöst hast - dieses geschieht mit dem Befehlt

svn resolved filenameEin weiteres svn commit läd nun endgueltig die lokale Version ins Repository.

Einen Schritt zurück

Falls man aus Versehen die falsche Datei modifiziert hat, kann man mit dem Revert-Befehl den Zustand nach dem update bzw. checkout zurueckstellen.

svn revert <Dateiname>Hinweis: Neben dem “von Hand mergen” ist dieses die 2. Möglichkeit einen Mergekonflikt zu lösen. Jedoch verliert man natürlich dabei seine eigenen Änderungen was nur in den seltensten Fällen praktikabel ist.

Einige Informationen aus dem Repository bekommen

Natürlich ist die Revisionsangabe optional. Wird keine Revisionsnummer angegeben, so wird die aktuellste Version aus dem Repository verwendet. Neben –revision kann man auch die Kurzform -r verwenden.

Eine ältere Revisionsnummer auschecken bzw. auf eine updaten

Auch beim Checkout- bzw. update Befehl kann man eine Revision wie in dem Absatz weiter oben angeben.

svn checkout --revision 1354 svn://<Servername>/<Pfad>Checkt den Inhalt mit der Revisionsnummer 1354 ins aktuelle Verzeichnis aus (update analog).

Aufräumen im Repository

Will man Dateien oder ganze Verzeichnisse im Repository umbenennen, verschieben oder kopieren ist dieses kein Problem. Analog zu den Standardkommandos cp, mv und rm gibt es svn copy, svn move und svn delete.

Das verwenden der “normalen” Dateioperationsprogramme (rm, …) sollte man meiden!

Mehrere Dateien importieren

Gerade zu Projektbeginn wird man haeufiger mehrere Dateien und Verzeichniss ins Repository anlegen muessen. Ist diese Struktur bereits lokal vorhanden, kann man diese komplett mit nur einem Befehl in ein Repository einfuegen.

svn import svn://<Servername>/<Pfad>/ -m "Initial import"Läd den Inhalt des aktuellen Verzeichnisses in das Unterzeichnis <Pfad> in das Repository.