Subversion: Unterschied zwischen den Versionen

Aktuelle Version vom 11. Mai 2012, 18:58 Uhr

Subversion (SVN) ist ein Tool zur zur Versionierung und gemeinsamen Entwicklung von Software.

Für eine detailierte Einführung siehe hier: [svnbook]

Installation

Debian/Ubuntu

Unter den meisten Linux Distributionen ist Subversion bereits installiert. Falls nicht kann man das einfach via Terminal nachholen:
apt-get install subversion

Windows

Mac OS X

Subversion installiert man am einfachsten, indem man die [Apple Developer Tools] von der Apple Website oder via Appstore runterläd und installiert.
Erfahrungsgemäß kann es vorkommen, das die Version die in den Developer Tools enthalten ist nicht die aktuellste ist. Die jeweils aktuelle Version kann man dann einfach via [Macports] installieren.
kurz:

1. Apple Developer Tools installieren
2. Macports installieren
3. mit port install subversion die aktuelle Version von Subversion installieren

Arbeitskopie anlegen

Üblicherweise beginnt man indem man aus einem bestehenden Repository die aktuelle Version auf den eigenen Computer überträgt. In dieser lokalen Arbeitskopie bearbeitet man den Code und überträgt die Daten später wieder zurück in das Repository.
Arbeitskopie anlegen:
cd /path/on/your/computer svn checkout protocol://user@host/remote/path/to/repository/trunk/src

typischer Arbeitsablauf

1. lokale Arbeitskopie anlegen (einmalig)
2. Arbeitskopie aktualisieren
3. Code lokal bearbeiten
4. Änderungen überprüfen und auf korrekte Funktion testen
5. Fehler korrigieren
6. Konflikte beheben
7. Änderungen in Repository übertragen

Arbeitskopie aktualisieren

cd /path/to/workingcopy svn update

Code lokal bearbeiten

Bearbeite den Code mit einem Editor deiner Wahl. Wenn du Dateien hinzufügst, löschst, kopierst oder verschiebst musst du SVN darüber informieren. Das macht man folgendermaßen:

svn add FOO

Füge die Datei oder den Ordner "FOO" zum repository hinzu. Wenn FOO ein Ordner ist werden automatisch alle Dateien die in dem Ordner sind mit hinzugefügt. Möchte man einen Ordner hinzufügen, ohne dass alle darin enthaltenen Dateien ebenfalls hinzugefügt werden, dann benutzt man zusätzlich die option --depth=empty.

svn delete FOO

Lösche die Datei oder den Ordner FOO aus dem Repository. Dateien werden im lokalen Dateisystem sofort gelöscht, Ordner erst beim nächsten commit.

svn copy FOO BAR

Kopiere die Datei FOO nach BAR. Die datei BAR wird automatisch zum Repository hinzugefügt und SVN speichert intern, dass BAR ursprünglich von der Datei FOO kommt.

svn move FOO BAR

Genauso wie FOO, aber BAR wird automatisch aus dem Repository gelöscht.

svn mkdir FOO

Kombiniert die Befehle mkdir FOO und svn add FOO in einen Befehl.

Änderungen überprüfen und Fehler korrigieren

Nachdem der Code angepasst wurde muss dieser auf korrekte Funktion getestet werden. Je nach Sprache und Entwicklungsparadigma werden hier Unittests o.ä. benutzt. Erst wenn sich die Änderungen fehlerfrei kompilieren lassen und der Code fehlerfrei läuft können wir den Code in das Repository überführen.
Als nützliches Werkzeug bietet Subversion die Möglichkeit alle geänderten Dateien aufzulisten mit dem Befehl

svn status

Nutzt man die Option -v wird der Status von allen Dateien angezeigt, auch wenn man diese nicht verändert hat.
Mit dem Befehl

svn diff

kann man sich in Menschen lesbarer Form alle Änderungen im Detail anzeigen lassen. Da die Ausgabe hier oft sehr umfangreich ist macht es meistens Sinn den Output in eine Datei umzuleiten mittels

svn diff > patchfile

Sollte man feststellen, das man in einer Datei grobe Fehler gemacht hat oder das man die falsche Datei bearbeitet hat, dann kann man alle Änderungen einer Datei mittels

svn revert FOO

auf den letzten unveränderten Stand zurücksetzen. Der revert Befehl funktioniert auch wenn man eine Datei fälchlicherweise hinzugefügt oder gelöscht hat.

Konflikte beheben

Wenn man sichergestellt hat, dass alle Änderungen korrekt sind müssen wir erst auf Konflikte mit anderen Benutzern prüfen, bevor wir die Änderungen in das Repository übertragen. Wenn z.B. zwei Benutzer unabhängig voneinander die gleiche Datei bearbeitet haben gibt es einen solchen Konflikt. Wir müssen dann von Hand die Änderungen der beiden Nutzer zusammenführen. Dazu führen wir als erstes ein update aus:

svn update
Updating '.':
U    INSTALL
G    README
Conflict discovered in 'bar.c'.
Select: (p) postpone, (df) diff-full, (e) edit,
       (mc) mine-conflict, (tc) theirs-conflict,
       (s) show all options: 

Da die Konfliktlösung sehr umfangreich werden kann verweise ich an dieser Stelle auf diesen Artikel: [Resolving Conflicts]

Änderungen in Repository übertragen

Nachdem alle Konflikte behoben wurden können wir unsere Änderungen in das Repository übertragen:

svn commit -m "kurze Beschreibung was geändert wurde und was sonst noch wichtig ist"

Wenn die commit message sehr umfangreich ist, dann ist es oft sinnvoll diese in einer separaten Datei anzulegen. In diesem Fall kann man einfach den Inhalt der Datei direkt an SVN übergeben mittels

svn commit -F logmessage

Tipps

1. kleine Veränderungen
Es ist besser nur kleine Veränderungen (z.B. nur an einer Datei) zu machen und anschließend zu commiten. So verringert man aufwendiges Merging.

2. regelmäßige Updates
Durch regelmäßige Updates verhindert man, dass man auf deralteten Daten arbeitet und durch ggf. bereits gepatchte Fehler weitere Fehler verursacht.

3. Absprache
Auch eine Versionsverwaltung wie SVN hilft nur dann, wenn man sich vorher abspricht. So kann man verhindern, dass mehrere Benutzer an einem Problem arbeiten oder die gleiche Datei editieren.
Es ist auch möglich für einzelne oder mehrere Dateien Locks zu setzen. Wenn ein Benutzer einen Lock setzt, dann kann nur er die Datei im Repository ändern, bis er den Lock aufhebt. Man sollte den Lock Mechanismus aber mit Vorsicht benutzen, da es schnell passieren kann, dass man vergisst den Lock wieder zu entfernen.

4. zusätzliche Tools
Meistens ist es von Vorteil neben dem reinen SVN auch noch andere Tools zu verwenden. So kann man andere Benutzer über Commits und Patches informieren. Hierfür eigenen sich z.B. Mailinglisten, Bugtracker oder ein Wiki.

siehe auch

Versionkontrolle mit GIT