fakeroot.at

Subversion-RichtlinienDeutsch

» Home » Programmieren » Subversion2009-04-08 12:32:17

Einleitung

Subversion ist ein Versionsverwaltungssystem. Es wird zum kollaborativen Arbeiten an einem Softwareprojekt verwendet.
Es überwacht Dateien, die unter Versionskontrolle stehen und verwaltet deren Änderungen in verschiedenen Revisionen (=eine Änderungseinheit).

Das so genannte Repository (die Sammelstelle aller Revisionen) ist zentral auf einem Server gespeichert (Subversion ist ein Server-orientiertes Versionskontrollsystem).

Es kann jederzeit zwischen den einzelnen Revisionen hin- und hergesprungen werden.

Alle Clients zeigen an, welche Dateien unter Versionskontrolle stehen und welche lokal verändert wurden.

Subversion ist keine File-Sharing Plattform!
Subversion ist auf die Verwaltung von Textdateien spezialisiert.
Mit großen Binärdateien kann es zwar auch umgehen, jedoch werden geänderte Dateien mehrfach im Repository gespeichert, was bei vielen großen Binärdateien zur Folge hat, dass das Repository relativ viel Speicherplatz verbraucht.

Benutzung

Checkout

Unter Checkout versteht man das herunterladen einer Working Copy (Arbeitskopie) aus dem Repository.
Nach dem Checkout hat man im Filesystem eine Ordnerstruktur, die dem Softwareprojekt zu einem gewissen Zeitpunkt entspricht (wenn nicht anders Angegeben zum Zeitpunkt des Checkouts).

Auch wird in jedem Ordner, der unter Versionskontrolle steht, ein Ordner namens .svn angelegt. Dieser beinhaltet alle Informationen, mit denen Subversion arbeitet und sollte unter keinen Umständen verändert werden!

Änderungen, die man macht, werden in dieser Working Copy durchgeführt und anschließend per Commit wieder ins Repository hochgeladen und somit anderen zur Verfügung gestellt.

Commit

Bei einem Commit werden die lokalen Änderungen wieder ins Repository hochgeladen. Zusätzlich kann (bzw. soll) eine Logmeldung angegeben werden, die kurz beschreiben soll, was konkret verändert wurde. Auch wird zu jedem Commit gespeichert, von wem dieser durchgeführt wurde. So können einzelne Commits später einfacher wiedergefunden werden.

Vor einem Commit sollte unbedingt ein Update durchgeführt und vorhandene Tests noch einmal durchgeführt werden!
Dies verhindert, dass sich mehrere gleichzeitige Änderungen von unterschiedlichen Personen an einer Datei (bzw. an der API) gegenseitig in die Quere kommen und sorgt dafür, dass sich im Repository idealerweise zu jedem Zeitpunkt eine lauffähige Version des Programms befindet.

Eine beliebte Praktik ist es, in den log messages auch zu erwähnen, wie lange man an der jeweiligen Änderung gearbeitet hat (z.B.: in eckigen Klammern: [15min]). Dies kann, wenn man es konsequent durchführt, zusätzliche externe Zeitlisten ersetzen.

Update

Update fragt beim Subversion-Server nach, ob die lokale Working Copy noch aktuell ist und aktualisiert diese nach Bedarf.

Eventuelle Konflikte zwischen Working Copy und aktueller Revision werden so gut es geht automatisch gelöst, was aber nicht heißt, dass die entstehenden Dateien korrekt kompilieren.

Grundsätzlich sollte vor jeder Änderung ein update und nach jeder Änderung ein update und erst nach erneuter Überprüfung des Programms ein commit erfolgen, um das Repository so gut wie möglich in einem konsistenten Zustand zu halten.
Manche Subversion Server sind so konfiguriert, dass ein commit nur dann erfolgt, wenn die Working Copy noch aktuell ist.

Graphische Clients

  • RapidSVN - Standalone-Applikation (Linux, Windows, Mac)
  • TortoiseSVN - In den Explorer integriert, sehr empfehlenswert für Win-User (nur Windows)
  • Subclipse - Subversion Eclipse Plugin (Java → Cross Platform)
  • Diverse Linux-Dateimanager bringen auch Clients mit bzw können per Plugins durch solche ergänzt werden.

Alternativ kann auch svn als Kommandozeilenprogramm verwendet werden (Hilfe zum Programm gibt's im Internet oder per svn help auf der command line)

Valid XHTML 1.0