svk, Subversion und mein Urlaub in den Tropen ohne Internet

Ich sitze zur Zeit recht häufig in der Bahn. Und manchmal will ich einfach auch mal wieder etwas ausprobieren. Also etwas programmieren. An Ideen mangelt es ja nicht. Und die .COM, bei der man Zeit zu günstigen Preisen ersteigern kann, ist auch noch nicht gebaut oder einfach nur in einem Universum außerhalb der bekannten Milchstraße bekannt. Oder bei Perry Rhodan, um das mal festzuhalten.

Marco hatte mir letztes Jahr erzählt, dass er (mehr oder weniger) dezentrale Versionskontroll-System svk ausprobiert hat und sowohl intuitiv als auch praktisch fände.
Und weil nun dsp supportete Vorträge über Versionkontroll-Systeme im Allgemeinen und unsupportete und private Vorträge über das dezentrale
Versionskontroll-System git hält, mit Hilfe dem u. A. auch der Linux-Kernel unter Versionskontrolle ist, dachte ich mir: "Probiers mal an einem Freitag Abend von München nach Würzburg im Zug aus, mach' dir ein eigenes Bild, bevor du dich ins Abenteuer git stürzt". - Ach ja, für den Toolset-Nazi: So ganz inoffiziell auf der private Debian-VM-Ware natürlich

Ein paar subjektive Fakts:

1. svk ist ein dezentrales Versionskontroll-System


2. Dezentral heißt, dass es kein zentrales Repository gibt, sondern dass sich Entwickler bei anderen Entwicklern bestimmte Versionen holen können und diese
   "unterschrieben" in ihr eigenes Reporsitory mergen können (ob nun in den Head oder einen Branch). Der andere Weg ist auch möglich:
   Ich schicke jemandem eine Version und der nimmt meine Änderungen an bzw. in sein Repository auf oder nicht.
   D.h. svk bietet die Möglichkeit, Versionen zwischen anderen (lokalen, verteilten) svk-Repositories zu mergen. Bei svk nennt man das smerge für Star-Merge - und die verwendeten Algorithmen erscheinen mit Abstand mit zu denken.
   
3. svk hat ein verwirrendes System für die Versionsnummern. Nämlich Zahlen wie Subversion. git ist da etwas eleganter. Bei git gibt es für jede Revision einen sha1-Key (ja, Autovervollständigung wird von den Kommando-Zeilen-Tools unterstützt...).


4. svk hat einen automatischen Synchronisierungs-Mechanismus, sodass man ein svk-Repository mit einem Subversion-Repository abgleichen kann.


5. svk bildet im Grunde eine neue API die auf dem Subversion-Filesystem basiert.


6. Weil 4) gilt, ergibt sich der sehr coole Impact, dass nämlich so ein svk-Repository über Subversion genauso angesprochen werden kann. Das werde ich später brauchen.


7. Weil svk ein dezentrales Gebilde ist - also jeder User hat ein eigenes Repository, wird man dieses Subversion-Filesystem unter Linux z.B. an der Stelle /home/xenjo/.svk finden.


8. Sprechen wir ein lokales svk-Repos über Subversion an, tun wir gut daran, eine Arbeitskopie wie folgt auszuchecken:
   
svn co file:///home/xenjo/.svk/repos/meinProjekt .

   (was man im Übrigen nicht allzuoft benötigt, es sei denn man will z.B. lokal die Subversion-Unterstüzung in Eclipse nutzen ).


9. svk ist sehr gut Dokumentiert und hat eine große Community.

Spielen

Installation etc. erkläre ich nicht. apt/aptitude etc. sollten das einfach machen.

Was werde ich machen? Also: Ich habe ein zentrales Subversion-Repository und will in den vier Wochen Urlaub beim Käfersammeln abends an einem Projekt arbeiten.

Oder sagen wir: Arbeiten und ausprobieren. Und ich weiß, dass jemand anderes in das zentrale Subversion committen wird, während ich kein Internet habe, weil ich
zufällig mein Handyladegerät vergessen werde. Aber mal im Ernst: Wer vier Wochen Urlaub bekommt, der macht sich sowieso auf einiges gefasst, wenn er wieder da ist...

In der Zeit will ich branches machen zwischen denen ich hin und her switchen möchte. Eine Patchsets will ich zusammen nehmen uns all so ein kram eben. Mir persönlich ist es darüber hinaus auch noch wichtig, dass ich manchmal für die Mergerei einen graphischen Diff hab und vielleicht auf meinem Rechner auch noch sowas wie websvn am laufen haben möchte. In das zentrale Subversion sollen aber nur Sachen rein, die auch wirklich alle Entwickler sehen sollen! D. h. ich möchte mir die Möglichkeit schaffen, einerseits wilde Experimente aufzuheben, andererseits will ich aber die genialen Dinge später zurück ins zentrale Subversion schieben...

Das zentrale Subversion-Repository sei "necrophlirt" und sei über WebDAV erreichbar unter https://svn.xenjo.org/necrophlirt.

Bevor ich in Urlaub fahre lege ich mir einfach ein Mirror-Repository mit svk an:

xenjo@linux:~/> svk mirror https://svn.xenjo.org/necrophlirt //mirror/necrophlirt

Man beachte die doppelten Slashes. svk legt den Mirror nun physikalisch unter /home/xenjo/.svk an (und hier wird man die Subversion-Files wie gewohnt unter local finden - das brauchen wir später unten nochmal).

Damit jetzt der Mirror das erste mal synchronisiert wird, verwendet man das Kommando sync:

xenjo@linux:~/> svk sync //mirror/necrophlirt

Jetzt wird jede Änderung im lokalen //mirror/necrophlirt bei Änderungen mit dem zentralen Subversion-Repository synchronisiert. Aber aufgepasst: ein Sync holt Änderungen vom zentralen Repository rein und schiebt lokale Änderungen hoch. Konflikte werden wie in Subversion gewohnt gelöst.

Jetzt kommt die kranke Magie ins Spiel.

Oben hatte ich geschrieben, dass ich experimentieren möchte. Ich will eben nicht, dass jede Änderungen in die Synchronisation kommt!
Das ist mit einem völlig probaten Mittel zu erreichen. Der Trick ist es, den "Mirror-Branch" zu branchen. Und damit es verständlicher wird, halte auch ich mich an die in svk-Kreisen bekannte Konvention "mirror" vs. "local":

xenjo@linux:~/> svk copy //mirror/xenjo //local/xenjo

Jetzt muss ich mir eigentlich nur noch ne Arbeitskopie auschecken und mit der Arbeit beginnen:

xenjo@linux:~/> svk co //local/xenjo .

Auf dieser Arbeitskopie kann ich mit den svk-Kommandos (die sich im Großen anfassen lassen wie die Subversion-Kommandos) operieren. Neue Branches erstellen, mergen, commiten etc.

Break. Jetzt kam eben die Frage aus der Mitte, ob man da jetzt auch mit Tortoise drauf kann. Nein, dass kann man nicht. Und ich weiß auch nicht, ob es GUI-Tools für svk gibt.

Aber die brauche ich für meine vier Wochen auch garnicht, denn ich hätte meine Arbeitskopie auch als Subversion-Repository auschecken können. Und damit keine Verwirrung den Spaß verdirbt, checke ich nicht ins Home-Directory aus, sondern gebe mir mal mühe, mit einem praxisnahen Beispiel:

xenjo@linux:~/> mkdir local
xenjo@linux:~/> cd local
xenjo@linux:~/local> svn co file:///home/xenjo/.svk/local/local/necrophlirt necrophlirt

Wobei das erste local von svk erstellt wird; hier liegt das Subversion-Filesystem. Das zweite local bezieht sich auf das Repository "//local/..." - in svk-Speech auch als Depot benannt.

Ich habe eben das ganze Repository ausgecheckt, das muss ich nicht, aber ich hab gerne alles bei einander, wenn nicht ein Praktikant auf die Idee gekommen ist, 1GB MP3's für Spielereien eben zu commiten.

xenjo@linux:~/local> ls -la necrophlirt
insgesamt 28
drwxr-xr-x 6 xenjo users 4096 3. Apr 01:49 .
drwxr-xr-x 4 xenjo users 4096 3. Apr 01:49 ..
drwxr-xr-x 3 xenjo users 4096 3. Apr 01:49 branches
drwxr-xr-x 6 xenjo users 4096 3. Apr 01:49 .svn
drwxr-xr-x 4 xenjo users 4096 3. Apr 01:49 tags
drwxr-xr-x 10 xenjo users 4096 10. Apr 20:07 trunk

Nun und der Rest ist dann wie gewohnt in Bezug auf Subversion. Nochmal, diese Arbeitskopie ist ein Subversion-Checkout und das Ergebnis ist eine Arbeitskopie,
die unter Subversion Versionskontrolle steht - das Repository in das ich commite dafür liegt aber lokal auf der Platte (zu Backup-Strategien gibts auch etliche Ansätze).

Einfaches Leben mit svk

Mal angenommen ich hätte nach dem Checkout bereits in den trunk commited. Und während ich das jetzt alles geschrieben habe, hat ein anderer Entwickler ein paar Bugfixes oder ein Feature eingebaut und seinerseits commited. Da ich ja noch nicht im Urlaub bin, will ich mein zunächst mein //mirror/necrophlirt aktuell haben. Meine Änderungen habe ich in //local/necrophlirt gemacht.

Zunächst hole ich mir alle Änderungen am zentralen Repository (pull), in dem ich das //mirror/necrophlirt synchronisiere (wobei es egal ist, in welchem Verzeichnis ich mich befinde).

xenjo@linux:~/local> svk sync //mirror/necrophlirt

Wenn ich meine letzten "lokalen" Änderungen (in //local/necrophlirt/trunk z.B.) in die Synchronisation schieben will, mache ich einen smerge:

xenjo@linux:~/> svk smerge //mirror/necrophlirt //local/necrophlirt

oder angenommen, ich habe einen gut funktionierendes Experiment im Branch "gutes-experiment-die-dritte" gebaut und will, dass dieser Branch später auch im
zentralen Repository landet, dann würde ich sowas machen:

xenjo@linux:~/> svk smerge //mirror/necrophlirt //local/necrophlirt/branches/gutes-experiment-die-dritte

Nochmal: alles was ich in den //mirror schiebe, landet mehr oder weniger im zentralen Subversion-Repository. Wenn nicht gleich, weil ich offline im Urlaub bin, dann doch spätestens dann wenn ich online bin. Ich kann die Synchronisation aber jeder Zeit mit:

xenjo@linux:~/> svk sync //mirror/necrophlirt

anstoßen.

Im zweiten Teil werde ich kurz beschreiben, wie ich svk im Zug oder im Urlaub unter Eclipse nutzen kann. Die einzigen Probleme die ich immer wieder hatte waren Unausgereiftheiten in meiner Eclipse Installation. Aber google sagt, ich bin nicht der einzige auf dieser Welt, also traue ich mich.

Weitermachen.

P.S., wer sich bis hier durchgekämpft hat wird sich freuen, dass man im Augenblick für die Verwendung von svk nur einen Link benötigt um auf schlechte Ideen zu kommen:

svk bestpractical