256bit.org Blog

Es kann eine ausgesprochen dämliche Idee sein, innerhalb eines Subversion-Repositories mittels der Eigenschaft svn:externals auf andere Unterprojekte zu verweisen.

SVK ist eine Software zur Versionsverwaltung.

Es benutzt dabei das Subversion Dateisystem als Backend und enthält zahlreiche zusätzliche Features wie Offline-Fähigkeit, erweiterte Merge-Algorithmen und die Möglichkeit externe Repositories zu spiegeln.

Wer schonmal aufgrund einer fehlenden Netzwerkverbindung auf einen Timeout von Subversion gewartet hat, der weiß die Vorteile einer dezentralen Versionsverwaltung zu schätzen.

SVK ist von der Syntax ziemlich ähnlich wie Subversion, kann also von Subversion Benutzern quasi analog genutzt werden.

Für mich ist ein Vorteil, dass innerhalb einer Working-Copy nicht überall diese .svn Verzeichnisse erstellt werden, was später das kopieren der eigentlichen Dateien ziemlich erschwerte.

Leider fehlen immernoch gute grafische Clients für svk. Eine Art TortoiseSVK wär wirklich nett. So ist das ganze zumindest unter Windows doch sehr eigenwillig zu bedienen.

Im Unterschied zu Subversion wird bei svk ein Repository als Depotpath bezeichnet (man erkennt das im Allgemeinen an den führenden Slashes), während die Working Copy, also das Arbeitsverzeichnis im Allgemeinen durch eine einfache Pfadangabe gekennzeichnet wird.

Hier ein Beispiel, wie man ein Repository spiegelt (um z.B. die Möglichkeit zu haben offline mit Subversion zu arbeiten):

Spiegeln eines externen SVN Repositories

1. SVK initialisieren:
cb:~$ svk depotmap -i
Repository /home/cb/.svk/local does not exist, create? (y/n)y
cb:~$

2. Den lokalen Mirror aufsetzen
cb:~$ svk mirror https://<URL-Repository> //mirror/repo
Committed revision 1.

3. Den lokalen Mirror synchen:
cb:~$ svk sync //mirror/repo
Syncing https://<URL-Repository>
Retrieving log information 1 to 25
Committed revision 2 from revision 1.
Committed revision 3 from revision 2.
[...]

4. Lokales Repository für Subversion anlegen:
cb:~$ svk cp //mirror/repo //local/repo

5. Nun kann das lokale Repository wie ein ganz normales Subversion Repository angesprochen werden:
cb:~$ svn co file:///home/user/.svk/local/local/repo repo

[ Update Working Copy, Commit Changes, etc... ]

6. Mirror mit externem Repository synchronisieren:
cb:~$ svk sync //mirror/repo

7. Änderungen in das lokale Repository mergen:
cb:~$ svk smerge //mirror/repo //local/repo

[ Working Copy von Subversion updaten ]

8. lokale Änderungen in den Mirror mergen:
cb:~$ svk smerge -C //local/repo //mirror/repo
-C steht für "nur Check durchführen", aber keine Änderungen machen (damit Konflikte aufgelöst werden können)
Wenn alle Konflikte gelöst wurden:
cb:~$ svk smerge -l //local/repo //mirror/repo


Nun sind alle Änderungen aus dem lokalen Repository auch in dem externen Repository enthalten (sofern man Schreibrechte besitzt).

Noch ein Beispiel?

/etc unter Versionskontrolle:

0. ein Depot initialisieren in /root/.svk
svk depotmap -i

1. Importiere alles aus /etc und mach das Verzeichnis zu einer Working Copy:
svk import --to-checkout //etc /etc

2. Beschränke die Lesbarkeit des Depots:
chmod -R go-rwx /root/.svk

3. evtl. nicht benötigte Dateien aus dem Archiv löschen
svk rm -K mtab ld.so.cache adjtime

4. Apt.conf anpassen, damit nach jedem Update auch die Änderungen übernommen werden:
echo DPkg::Post-Invoke {"svk commit //etc";}; >>/etc/apt/apt.conf


Grad sehe ich, dass SVK 2.0 gerade erst freigegeben worden ist. Als neue Features werden genannt:

• Interactive Commits
• View support
• Log Filter Plugins
• Unterstüzung von svn dump für svk mirrors

Sehr interessante Entwicklung.