subversion (svn)


Ein Subversion (version 1.1.3-1) Repository ist auf dem Server "terra" (129.206.78.104) installiert und kann mit Hilfe WebDAV-fähiger subversion-Clients wie z.B. tortoise , oder subclipse über die URL:
"https://terra.informatik.uni-heidelberg.de/svn/cip-pool"
erreicht werden.



Im folgenden wird nur auf die Nutzung des eclipse Plug-in "subclipse" zur Arbeit mit Subversion eingegangen, da dies OS-unabhängig sowohl auf Windows als auch Linux Rechnern verfügbar ist.


Zusammenarbeit von eclipse mit subversion

Voraussetzungen:
Zur Installation von eclipse & der JAVA-Umgebung ist es lediglich erforderlich die entsprechenden *.zip bzw *.tgz Dateien in beliebigen Verzeichnissen auszupacken.
Das/die notwendige(n) Plug-in(s) können anschliessend in eclipse nachgeladen werden (siehe folgender Abschnitt)

Fertige Pakete von eclipse (3.01), die bereits alle notwendigen Plug-ins beinhalten sind auf CDROM verfügbar und können zur Installation ausgeliehen werden

Damit eclipse auf svn-Repositories zugreifen kann, muss zunächst einmal das subversion-Plug-in "subclipse" geladen werden. Dazu wird in eclipse der Menüpunkt Help->Software Updates->"Find and install.." ausgewählt. "Search for new features" gewählt und als Update-site die URL "http://subclipse.tigris.org/update" angegeben.
Eclipse versucht Kontakt zur angegebenen website aufzunehmen und dort das Plug-in "subclipse" zu finden & zu installieren (Linux-Benutzer gehen für die Installation des JAVAsvn Plug-in entsprechend vor, wählen dabei als Update-site "http://tmate.org/svn/".
Ist das Plug-in installiert, steht eine weitere Perspektive "SVN Repository Exploring" zur Verfügung. Hier kann mit NEW->Repository Location die URL "https://terra.informatik.uni-heidelberg.de/svn/cip-pool" für den Zugriff auf das Repository angegeben werden.
Nach Angabe von Kennung & Passwort wird der Zugriff auf Teile des Repositories gewährt. Die Authentifizierung findet über den LDAP-Server des CIP-Pool statt, d.h. die anzugebende Kennung & Passwort entsprechen denen des CIP-Pool.




Grundsätzlich ist die Verwendung von subclipse vergleichbar der des eclipse cvs-Client, einige Unterschiede bestehen jedoch, daher werden im folgenden typische Anwendungsbeispiele dargestellt

Aufgabe 0.: Daten sollen aus dem svn-Repository geholt werden und als neues Projekt im Workspace des Benutzers abgelegt werden.

Vorgehensweise:


Aufgabe I.: Eine neue Datei (neue Dateien) werden lokal erzeugt und sollen ins Repository aufgenommen werden

Vorgehensweise:


Aufgabe II.:ein Projekt ist lokal vorhanden und soll als Ganzes in die Versionierung durch subversion importiert werden

Vorgehensweise:
=> in der svn-Sicht ist (nach Aktualisierung) nun ein modul "html-seite" unterhalb von "trunk" zu finden; das modul ist zunächst noch leer, muss per commit erst mal mit Daten gefüllt werden. Wie zu erwarten, stellt eclipse beim Versuch zu "commiten" fest, dass einige Dateien nicht unter Versionskontrolle sind (können mit "details" aufgelistet werden) und bietet die Aufnahme in die Versionskontrolle an. Nach einem YES werden die Dateien auf den svn-Server übertragen.




Aufgabe III.:Ein Projekt wurde von 2 Benutzern ausgecheckt, zwischenzeitlich hat der 1te Benutzer geänderte Daten auf den Server zurückgeschrieben (commit); nun will der 2te Benutzer seine geänderten Daten ebenfalls zurückschreiben

Vorgehensweise: Anschließend funktioniert auch das commiten dieser Datei !




Aufgabe IV.: von einem "trunk" wird ein Zweig (branch) genommen, der sich weiterentwickelt und schließlich mit anderen branches bzw. mit dem trunk vereinigt wird.
=====================================================
Einschub: in subclipse kann die bewegte Geschichte einer versionierten Datei mit Hilfe von Team-"show in resource history" betrachtet werden.
=> diese Log-Daten sind beim späteren mergen diverser branches/trunks wichtig!!

======================================================




Aufgabe V.: Von einem Trunk wurde ein Branch abgespalten - beide Bereiche (Trunk & Branch) haben sich unabhängig voneinander weiter entwickelt und sollen nun wieder zusammengeführt (gemerged) werden.


Vorgehensweise:
durch "update" & "commit" wurden die jeweils aktuellen Entwicklungsstände von den lokalen Arbeitsbereichen (unterschiedlicher Rechner/Projektmitarbeiter) auf den Server geschrieben.
Auf dem Rechner, auf dem Trunk und Branch zusammengeführt werden sollen, wird zunächst der aktuelle Trunk aus dem Repository in den workspace geladen (z.B. mit "checkout"). Anschliessend wird die Entwicklung des Branch untersucht. Dies geschieht entweder in der Resourcenansicht über Team -> "show in Resource History" (falls man den aktuellen Stand im Workspace hat) oder in der svn-Resourcen Sicht über "show in Resource History".
Hier sucht man die erste Revision, die nach der Abspaltung des Branch vom Trunk entstand. Die gesuchte Revision weist erstmals den aktuellen Pfad "./branches/.." auf, während alle früheren Revisionen noch "./trunk/.." als Pfadangaben aufweisen.

Branch Revision vor der Trennung vom Trunk

Branch Revision unmittelbar nach der Trennung vom Trunk

In unserem Fall ist der Branch "1a" als Revision 87 vom Trunk abgespalten worden. Sollen Beide Bereiche wieder zusammengeführt werden, muss der Trunk (in unserem Arbeitsbereich mit dem Branch des Repository ab Revision 87 gemerged werden.

merge Trunk mit Branch

Consolen-output wie folgt:
merge -r87:HEAD https://terra.informatik.uni-heidelberg.de/svn/branches/1a C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk
C C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk/1
C C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk/a/1
C C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk/2
C C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk/b/1
C C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk/b/2
A C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk/b/3
Skipped C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk/c
A C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk/c/1
 proplist C:/Programme/eclipse3.0.1/eclipse/workspace/1a-trunk


Wie zu erwarten ist es beim mergen zu Konflikten (C) gekommen, nur einige Dateien des Branch konnten direkt in den Trunk aufgenommen (A) werden.



-> erst nachdem alle Konflikte gelöst wurden (siehe Aufgabe 3) kann das Resultat per commit in den Trunk des Repository überführt werden.
=> Ergebnis: der Trunk enthält jetzt alle Änderungen, die im Branch wie im Trunk durchgeführt worden sind !!!

weitere Informationen im Internet: