versionsverwaltung:subversion

Versionverwaltung mit Subversion

Subversion ist eine freie Software zur Versionsverwaltung. Es legt eine lokale Arbeitskopie ab, mit der normal (und offline) gearbeitet werden kann. Änderungen werden nur noch als Delta (Differenzübertragung) übertragen, was sowohl beim Abgleich mit subversion-Repositorys als auch beim upload Zeit und Bandbreite spart. Konflikte können in den meisten Fällen automatisch aufgelöst werden.

Gegenüber dem alten CVS wurden einige Unzulänglichkeiten beseitigt, z. B. beim Umbenennen von Dateien.

Zugriffsmöglichkeiten
Schema Zugriffsart
file:/// direkter Zugriff (lokales Verzeichnis) auf das Repository
http:// Zugriff über Webserver (mit WebDAV und svn-Erweiterung)
https:// wie oben aber mit SSL-Verschlüsselung
svn:// Zugriff auf einen svnserve-Server
svn+ssh:// wie oben, aber durch einen SSH-Tunnel

siehe auch:

Links

how-to

Zusatzscripte

Clients

ausführlichere Liste von Subversion Clients.

Linux

  • die Subversion-Kommandozeilentools (CLI)
  • RapidSVN

Windows

Web

Plattform-neutral

Begriffe

  • Repository: der Ordner für die Projekte, dieser liegt lokal in einem Verzeichnis oder auf einem (Web-)Server
  • check-out: um eine Arbeitskopie (working copy) zu erhalten muss man das aktuelle Repository (bzw. einen Unterzweig davon) exportieren. (svn checkout http://URL.de/repository/Unterzweig)
  • check-in oder commit: Änderungen hochladen, dabei weder entweder alle Änderungen eingefügt oder gar keine, das Mischen von Datenbeständen aufgrund von Verbindungs- oder sonstiger Probleme kann also nicht passieren.
  • update: die lokale Arbeitskopie wird auf den Stand des Repository gebracht indem Änderungen in die Arbeitskopie einfließen (s.u.).
  • working copies (Arbeitskopie): Kopien des Repository, die Benutzer können damit beliebig arbeiten und Änderungen werden erst mit einer expliziten Anweisung hochgeladen.

:!: Eine ausführlichere Erklärung: Vokabular der Versionsverwaltung

Organisation in Subversion

In der Open-Source-Szene hat sich eine Struktur durchgesetzt, die externen Entwicklern eine schnelle Orientierung ermöglichen.

Üblicherweise findet man drei Ordner:

  1. „Trunk“ speichert den jeweils aktuellen Stand eines Projekts.
  2. „Tags“ sind in der Regel Zwischenstände
  3. „branches“ sind so genannte Zweige. Hier könnte z. B. der stabile Entwicklungszweig (für den Produktiveinsatz) abgelegt sein, der parallel zum Entwicklungszweig läuft.

Siehe auch: Repository Layout.

Zustände von Dateien

Dateien in Arbeitskopien können dabei in einer der vier Zustände sein:

  1. Unchanged, and current (unverändert und aktuell): Die Datei ist unverändert und es wurden keine Änderungen an das Repository übermittelt (commited). Also hat ein commit oder update hier keine Auswirkung (da unverändert auf beiden Seiten).
  2. Locally changed, and current (lokal verändert und aktuell): Die Datei wurde im Arbeitsverzeichnis geändert, im Repository wurden aber seit der Basis-Revision keine Änderungen anderer Benutzer eingereicht. Ein commit wird die Änderungen einreichen, ein update wird nichts tun (da die lokale Datei neuer ist).
  3. Unchanged, and out-of-date (unverändert und veraltet): Nun der umgekehrte Fall, die Datei wurde im Arbeitsverzeichnis nicht geändert, im Repository wurden aber seit der Basis-Revision Änderungen eingereicht. Also wird ein commit nichts bewirken, ein update aber die letzte Version aus dem Repository laden.
  4. Locally changed, and out-of-date (lokal geändet und veraltet): Der Konfliktfall, man hat selbst Änderungen in der Arbeitskopie gemacht und auch jemand anderes hat Änderungen eingereicht. Ein commit wird mit einem „out-of-date“ (veraltet)-Fehler scheitern. Daher muss man zuerst ein update vornehmen, dabei wird subversion zuerst versuchen die Änderungen im Repository automatisch mit denen in der lokalen Arbeitskopie zu verbinden („mergen“). Wenn das nicht automatisch klappt (z.B. Änderungen an der gleichen Stelle), muss der Benutzer den Konflikt auflösen.

Nach Eingabe von 

svn update

wird die lokale Arbeitskopie auf den neuesten Stand gebracht, dabei entstehen Ausgaben wie: 

U  INSTALL
G  README
C  bar.c
Updated to revision 46.
Status Bedeutung
U Updated: Lokal nicht geändert, die neue Version aus dem Repository wird heruntergeladen
G merGed: Lokale und fremde Änderungen konnten ohne Probleme verschmolzen werden.
C Conflict: Ein Problem trat beim Verschmelzen (mergen) lokaler und fremder Änderungen auf. Dies ist vor allem der Fall, wenn bei Textdateien wo an der gleichen Stelle bearbeitet wurde oder einge Binärdatei ersetzt wurde. Bei Binärdateien ist keine Lösung möglich, man muss sich für eine der beiden Dateien entscheiden. Bei Textdateien muss man manuell nachbessern (von Hand mergen). Solange bleibt die entsprechende Datei im Konflikt.
D Deleted: In der Arbeitskopie gelöscht.
A Added: In der Arbeitskopie hinzugefügt.

typische Aufgaben

Vorgensweise: Repository anlegen

  1. Ein lokales Repository anlegen: 
    svnadmin create /Pfad
  2. Rechte für den Benutzer (z. B. beim Abruf über Apache www-data) setzen: 
    cd /Pfad
 chown -R www-data *
  3. Eine (leere) Arbeitskopie in einem anderen Verzeichnis erstellen: 
    svn checkout file:///Pfad
  4. Dateien erstellen, bearbeiten; danach diese bei Subversion anmelden: 
    svn add datei1 datei2

    . Dateien kann man mit 

    svn delete datei1 datei2

    auch wieder entfernen.

  5. Änderungen übertragen: 
    svn commit -m "Kommentar für die Änderungen"

Projekt importieren

svn import [VERZECHNIS] file:///var/svn/projekt -m "erster Import"

Dann sollte man in etwa so etwas erhalten 

Hinzuf. (bin)  [VERZECHNIS]/images/bild.gif
Hinzufügen     [VERZECHNIS]/webseite.htm

Revision 1 übertragen.

Pfadnamen in Windows, die auf einem anderen Laufwerk liegen, müssen übrigens so angegeben werden: 

file:///X:/Pfad

bzw. 

"file:///X|/Pfad"

die Anführungsstriche sind wichtig damit svn nicht das Pipe-Symbol ( | ) als Befehlstrenner interpretiert.

Das ganze geht natürlich auch übers web: 

svn import /ORDNER/ svn+ssh://example.com/var/svn-repos/project_1/Ordner -m "gewünschte Meldung im Log"

eine Arbeitskopie erstellen (checkout)

Eine lokale Arbeitskopie (bzw. ein checkout) erstellt man mit 

svn checkout svn+ssh://domain.de/Pfad/zum/Projekt  --username USER

hier benutzt subversion ssh und checkt dann die aktuelle Version auf dem Server „domain.de“ aus dem Verzeichnis „Pfad/zum/Projekt“ aus.

Wenn man eine bestimmte (ältere) Revision haben will, muss man den Parameter -r und die Nummer der Revison angeben. Weitere Möglichkeiten listet die Hilfe mit dem Befehl svn help checkout auf.

:!: Als Kurzschreibweise für checkout kann man auch co schreiben.

Dateien auflisten

svn list https://domain.de/projekt --username USER

Änderungen verfolgen

Erstmal ins Verzeichnis der Arbeitskopie wechseln.

Die Bearbeitungshistorie ergibt sich auch durch die Bearbeitungshinweise der einzelnen „Committer“. Diese Liste kann mit dem Befehl 

svn log

abrufen.

Lokal geänderte und neue (lokale) Dateien gibt der Befehl 

svn status

aus. Dabei werden Statuscodes verwendet.

Buchstabe Statuscode
A Additon: Datei/Verzeichnis/Symbolischer Link wurden für die Aufnahme in das repository ausgewählt.
C Conflict: Die Datei ist im Konflikt
D Deletion: Datei/Verzeichnis/Symbolischer Link wurden für die Löschung im repository ausgewählt.
M Modified: Die Datei wurde lokal geändert.

Die Änderungen in den Dateien kann man mit 

svn diff

auswerfen lassen. Optional kann man eine bestimmte Revision zum Vergleich auswählen: -r1. Die Änderungen bei Binärdateien sind natürlich wenig Aussagekräftig. ;-)

Die letzte im Repository gespeicherte Version gibt der Befehl 

svn cat DATEI

aus. Bei Bedarf kann auch eine spezieller Revision mit der Option -r VERSION abgerufen werden.

Beispiel: Änderung zwischen Revision 2 und 3 betrachten: 

svn diff -r 2:3 [Datei]

Die Änderungen können auch wieder auf die letzte bzw. eine ältere Version zurückstellen: 

svn revert

Änderungen hochladen (commit)

Wenn man sich eine Arbeitskopie erstellt hat, geht das hochladen von Änderungen ohne weitere Angaben: 

svn commit

einen Konflikt beheben

Es trat ein Problem beim Verschmelzen (mergen) lokaler und fremder Änderungen auf, die subversion nicht automatisch auflösen kann. Deshalb legt subversion drei Dateien an:

  1. DATEINAME.mine : die lokal geänderte Datei vor dem update. Wird nur dann nicht erstellt, wenn subversion davon ausgeht, dass die Datei nicht zu verschmelzen geht)
  2. DATEINAME.r[Nummer der alten Revision] (z.B. DATEINAME.r45): Die letzte ausgecheckte Version. Damit war sie Basis für die lokalen Änderungen die dann zum Koflikt geführt haben.
  3. DATEINAME.r[Nummer der neuen Revision] (z.B. DATEINAME.r46): Die letzte (und aktuelle) Version aus dem Repository.

Den Konflikt einer Datei (Status C) kann man auf drei Arten beheben:

  1. Manuell (durch Editieren) den Konflikt auflösen. Dazu schaut man sich die konkurrierenden Änderungen mit 
    svn diff

    an und macht eine gemeinsame Version draus. Wenn man sich sicher ist, den Konflikt gelöst zu haben, wird die Datei mit 

    svn resolved DATEINAME

    gekennzeichnet und löst danach ein commit aus. 

    svn commit -m "Fall gelöst"
  2. Sich für eine der temporären Dateien entscheiden: Man kopiert eine der drei angelegten Dateien (s.o.) auf DATEINAME und gibt 
    svn resolved DATEINAME

    die Entscheidung bekannt.

  3. Die lokalen Änderungen komplett verwerfen: 
    svn revert DATEINAME

Eigenschaften von Dateien

Manchmal will man bestimmten Dateien permanent Eigenschaften zuweisen, beispielsweise Programme als ausführbar zu markieren: 

svn propset svn:executable ON DATEI

URL des Repositories ändern

svn switch --relocate Quell-URL Ziel-URL

Konfiguration

Installation: subversion und websvn

Kurzfassung des Artikels Setting up Subversion and websvn on Debian, ist zu hastig für Einsteiger, aber ich brauchs als Erinnerung ;-)

  1. subversion incl. Apache2-Modul installieren (als root bzw. mit sudo): apt-get install subversion libapache2-svn
  2. Verzeichnis für das Repository anlegen: mkdir /var/svn-repos/
  3. Gruppe für Subversion erstellen und Benutzer hinzufügen: groupadd subversion und addgroup [USER] subversion
  4. Verzeichnisrechte erteilen: chown -R www-data:subversion /var/svn-repos/* und chmod -R 770 /var/svn-repos/*
  5. Repository erzeugen: svnadmin create --fs-type fsfs /var/svn-repos/project_1
  6. Module für Subversion WebDAV aktivieren: a2enmod dav dav_svn
  7. Apache2 konfigurieren: in /etc/apache2/sites-available eine Datei mit beliebigem Namen anlegen (z.B. svn) und mit folgendem Inhalt befüllen (Alias svn_projekt, SSL, WebDAV sowie Passwortschutz) :
<Location /svn_projekt>
    DAV svn
    SVNPath /var/svn/projekt
    AuthType Basic
    AuthName "Infosystem Subversion Repository"
    AuthUserFile /etc/apache2/dav_svn.passwd
    Require valid-user
    SSLRequireSSL
</Location>
  • Syntax überprüfen: apache2 -t
  • Apache2 neustarten: apache2ctl restart ODER /etc/init.d/apache2 restart

LDAP-Config und andere Info siehe hier.

anderer SSH Port

Wenn man einen anderen SSH-Port als 22 benutzt, muss man dieses Subversion mitteilen. Dies geht entweder über eine Umgebungsvariable: 

export SVN_SSH="ssh -p 123456"

oder man konfiguriert ssh.

Troubleshooting

  • Arbeitskopie gesperrt („working copy locked“): 
    svn cleanup