Dezentralisiertes Subversion Repository II

Nachdem ich im Herbst letzten Jahres über ein dezentrales Subversion-Repository mittels svn-git geschrieben habe, kam die Frage von Kai nach der Verwendung von SVK auf. Hier nun meine Erfahrungen.

SVK ist ein in Python geschriebenes dezentrales Versionskontrollsystem, welches im Hintergrund Subversion zum Speichern aller Informationen einsetzt. Zugreifen kann SVK auf CVS-, Perforce-, Subversion-, Arch- und cvsbk-Repositories. Die Aufrufe auf der Kommandozeile sind stark an denen von Subversion angelehnt.

Als erstes wird SVK installiert. Das ist in Debian denkbar einfach.

Um Zugriff auf ein entferntes Repository zu erlangen, muss SVK dieses lokal spiegeln. Dazu braucht das SVK-Dateisystem einen Ordner, den ich mirror benenne. In diesen Ordner kann ich nun ein entferntes Repository oder nur einen Zweig eines entfernten Repositorys spiegeln. Ist der Spiegel eingerichtet, muss er noch synchronisiert werden. Dabei werden sämtliche Revisionen aus dem entfernen Repository in das lokale SVK-Repository übernommen. Bei großen Repositories kann es daher von Vorteil sein, nur den Zweig zu spiegeln, in dem man auch bearbeiten möchte.

SVK arbeitet so, dass alle Commits, die direkt in den Spiegel-Ordner //mirror erfolgen, sofort in das entfernte Repository eingespielt werden. Da es aber möglich sein kann, dass einmal keine Verbindung zum entfernten Repository besteht, muss der gespiegelte Ordner in einen lokalen Arbeitsordner kopiert werden.

Die so angelegte lokale Kopie kann nun ausgeschleust werden.

Danach habe ich eine lokale Arbeitskopie vom Trunk meines Projektes. Hier kann ich munter drauf los arbeiten und mittels add, move und delete auch Änderungen in der Verzeichnisstruktur vornehmen. Nach getaner Arbeit bzw. in gewissen Abständen werden die Änderungen der lokalen Arbeitskopie in das SVK-Dateisystem überspielt.

Die so gemachten Änderungen residieren im SVK-Dateisystem auf der lokalen Platte. Bis zu dem Zeitpunkt an dem der lokale Spiegel mit dem entfernten Repository abgeglichen wird. Einmal können Änderungen vom entfernten Repository in den lokalen Spiegel geholt werden und zum anderen können lokal comittete Änderungen in das entfernte Repositoy überspielt werden.

Da SVK für sein Dateisystem lokal ein SVN-Repository anlegt und es wunderbare Subversion-Clients wie z.B. QSvn gibt 😉 , liegt es nahe sich die lokale Arbeitskopie nicht mittels svk checkout sondern per Subversion-Client auszuschleusen. In der so angelegten Arbeitskopie kann dann in gewohnter Subversion-Umgebung gearbeitet werden. Bleibt dort nur noch das svk pull und svk push

Dezentralisiertes Subversion Repository II
Markiert in:     

Kommentar verfassen