Seiten

Categories

Archive

Tags

development gem linux merge rails redcloth ruby server subversion svn typo windows

Syndikat

Subversion 1.5 - endlich ;)

Seitdem ich davon gehört habe, daß man mit der Version 1.5 von Subversion (subversion.tigris.org) eine bessere Verwaltung für das Zusammenführen von Branches (auch mergen genannt -> siehe Beitrag "branches und merge in Subversion") versuche ich, meinen Server auf diese Version upzudaten.

Leider - wie immer - nicht ganz trivial.
Es gibt für Debian (zumindest für die Anhänger des stabilen Zweigs, wie ich) keine Subversion 1.5 Pakete. Das heißt, es bleibt mal wieder nur, die ganze Sache selbst zu compilen. Frühere Versuche, einfach die Quellen von 1.5.2 zu compilen, habe ich nach ein paar Versuchen aufgegeben.

Jetzt habe ich aber noch mal etwas Zeit investiert und herausgefunden, daß es ein Paket mit Dependencies direkt von den Jungs von Tigris zu Subversion dazu gibt. Das macht es viel einfacher. Ich habe also die Version 1.5.4 runtergeladen nebst dem subversion-deps Paket und es kompiliert. Zu meiner großen Überraschung ließ sich das ganze mit den Befehlen

$ tar xzvf subversion-1.x.x.tar.gz
$ tar xzvf subversion-deps-1.x.x.tar.gz
$ cd subversion-1.x.x
$ ./configure
$ make
$ make install

einfach compilen und installieren. Dann fehlte mir noch die Unterstützung für das Berkeley DB Datenbank-Format, daß ich bei meinem Server verwende. Also habe ich die entsprechenden Quellen für Berkeley-DB 4.x von Oracle (http://www.oracle.com/technology/software/products/berkeley-db/index.html) runtergeladen, übersetzt und installiert.

Danach die Befehle von oben ab ./configure nochmal wiederholt und alles war in Butter.

Um meine "alten" Subversion-Repositories benutzen zu können mit der neuen Version, war ein kurzes

svnadmin recover [repository-path]

nötig. Danach funktionierte es einwandfrei.

Leider habe ich es noch nicht geschafft, die merge-Funktionen richtig zu testen. Aber das werde ich mit Sicherheit bald tun. Bis dahin viel Glück an alle, die ähnliches vorhaben. Die komplette Anleitung findet man unter http://svn.collab.net/repos/svn/trunk/INSTALL.

Angelegt von Janko Wed, 29 Oct 2008 11:07:00 GMT


branches und merge in Subversion

Ich benutze Subversion (oft auch "svn" genannt, weil das Kommando in der Konsole so heißt) schon seit vielen Jahren. Ich hab damals in der iX davon gelesen und bin seit Version 1.0 dabei.
Trotzdem muss ich zugeben, daß ich bis gestern nicht so wirklich wußte, wie und warum man überhaupt branches macht.

Ein Branch in Subversion ist im Prinzip eine Kopie des Programms (eigentlich Quellcodes), die man an einem gewissen Punkt erzeugt, wenn man vorhat größere Änderungen daran zu machen. Denn man geht davon aus, daß im Zuge dieses Prozesses viele Dateien verändert werden müssen und es länger dauert bis man wieder eine stabile Version bekommt. Damit man trotzdem in den Genuss der Versionsverwaltung kommt, macht man eine neue Branch auf.

Wie gesagt, in Subversion ist eine Branch im Prinzip erstmal nur eine Kopie, die man anlegt. Also kopiert man einen Teil des Subversion-Baums an eine geeignete Stelle:

svn copy
svn://svn.domain.de/projekt1/hauptversion svn://svn.domain.de/projekt1/branch1

Ja, richtig gesehen, mit diesem Befehl braucht man nicht einmal eine lokale Kopie ausgecheckt haben. Man kann direkt auf dem Subversion-Repository arbeiten und dann später die Branch auschecken mit

svn checkout svn://svn.domain.de/projetk1/branch1

Das schöne an dieser Lösung ist, daß man in Ruhe an der neuen Version oder größeren Veränderung arbeiten kann, während man noch die alte stabile Version verfügbar hat und daran auch noch z.B. Bugfixes machen kann. Wenn man also während der Arbeit an der Branch einen Fehler findet, den man sofort auch in der stabilen Version ändern will, checkt man die stabile Version aus und ändert das. So hat man die stabile Version verbessert (im Zweifel sicherer und benutzbarer gemacht) ohne daß man gleich alle Änderungen an der Branch fertig haben muss.

Im Prinzip ist die Idee dahinter, daß man hinterher die Änderungen an der Branch und der stabilen Hauptversion "mergen" kann. Also so wie Subversion normalerweise die Änderungen im Quelltext bei einer neuen Revision einfügt und dabei versucht, verschiedene Änderungen an der gleichen Datei unter einen Hut zu kriegen. Das wäre natürlich der Idealfall. Man macht eine Menge Änderungen in der Branch und ein paar Bugfixes in der Hauptversion und hinterher gibt man einen Befehl ein und hat auf einen Schlag alle Änderungen aus beiden Versionen zusammen.

Das wäre wirklich ziemlich cool. Leider sieht die Wirklichkeit im Moment noch etwas anders aus. Ich habe das gestern mal versucht und musste leider feststellen, daß bei Änderungen an der gleichen Datei in der Branch und der Hauptversion (oft als "trunk" bezeichnet [kurzer Exkurs: trunk heißt Stamm, ist also die Hauptversion, während branch Ast heißt und demnach vom Stamm abgeht]) immer zu einem Konflikt führt. In meinem Fall waren das 5 Dateien. Ärgerlich dabei ist vor allem, daß die Änderungen sich auf 1 - 2 Zeilen beschränkten, die auch noch an ganz verschiedenen Stellen in der Datei standen. Normalerweise hätte Subversion die Änderungen einfach zusammengefügt und alles wäre grün gewesen.

Soweit ich das bisher mitbekommen habe, unterstützt die neue Version 1.5 von Subversion eine etwas bessere Form des "mergens". Dabei werden dann noch Meta-Informationen zu den Dateien gespeichert, z.B. ob eine Datei schon mit einer anderen Version aus einem Branch zusammen-gemerged wurde oder nicht. Wie schon gesagt, wenn das wirklich funktioniert wäre das super und ich sofort noch mehr Fan von Subversion als bisher schon.

Details zum Nachlesen findet man hier: Subversion Book (allerdings noch zu Version 1.4)
Die neue Version von Subversion (1.5) gibt’s auf der Herstellerseite - natürlich kostenlos. Es gibt auch noch eine Profi-Version bei CollabNet, dafür muss man sich allerdings registrieren.

PS: Eine alternative zu Subversion ist GIT, daß aus dem Ruby und Ruby on Rails Umfeld stammt und dessen Server natürlich mit Ruby on Rails läuft. GIT hat einige Features, die Subversion (noch) nicht hat und wird immer beliebter. Eine gute erste Anlaufstelle dafür ist GitHub.

Angelegt von Janko Fri, 25 Jul 2008 10:52:00 GMT