Beiträge getagged ‘Subversion’

Wird es Zeit, sich Git anzusehen?

8 Juli 2009

In den letzten Wochen und Monaten habe ich immer mehr Berührung mit dem Verwaltungssystem Git bekommen. Sei es durch eine Vielzahl an Plugins für Ruby on Rails, die auf github gehostet werden, oder die seit einigen Wochen öffentlich zugänglichen Qt Quellen auf Gitorious. Und heute kam die Meldung, dass auch KDE von Subversion auf Git wechseln möchte.

Wird es also Zeit für mich einmal einen näheren Blick auf Git zu werfen? Dabei stellen sich mir die Fragen, wie ich einen Server installiere, über welches Protokoll greif ich auf ihn zu. Wie handhabe ich Zweige, Commits, Merges und wie sehe ich mir das Log an? Alles Fragen, die ich mir in Zukunft sicher einmal beantworten werden. Wenn es soweit ist, könnt ihr an dieser Stelle die Antworten darauf lesen. :)

Subversion-Repositories zusammenfassen

6 Januar 2009

Auf meinem Subversion-Server lungern jede Menge kleinere Repositories herum, die ich im Laufe der Zeit angelegt habe. Nun macht die steigende Anzahl an Repositories das Handling derselbigen nicht gerade übersichtlich. Was liegt da also näher, als einige kleine Repositories, die thematisch zusammenpassen in einem Repository zusammenzufassen? Dank svnadmin ist das fast ein Kinderspiel :)

In meinem Beispiel-Szenario gibt es zwei Repositories (proj1 und proj2), die in einem neuen (projects) zusammengefasst werden sollen. Dabei soll im neuen Repository die beiden alten jeweils unterhalb eines eigenen Verzeichnisses /proj1/ und /proj2/ hausieren.

Um das zu erreichen brauch ich als erstes ein neues Repository.

svnadmin create /var/svn/projects

Das eben erstellte Repository schleuse ich mir aus und lege die Verzeichnisse für die beiden Projekte an.

cd ~
svn co file:///var/svn/projects projects
cd projects
svn mkdir proj1
svn mkdir proj2
svn commit . -m "Verzeichnisstruktur angelegt"

Nun kann ich mir per svnadmin Dumps der alten Repositories anlegen und diese jeweils unterhalb der eben erzeugten Verzeichnisse in das neue Repsoitory einspielen.

svnadmin dump /var/svn/proj1 > proj1.dump
svnadmin dump /var/svn/proj2 > proj2.dump
svnadmin load /var/svn/projects --parent-dir /proj1/ < proj1.dump
svnadmin load /var/svn/projects --parent-dir /proj2/ < proj2.dump

Und fertig ist das neue Repository mit dem Inhalt der zwei alten. Sogar die Historie ist erhalten geblieben. Einzig die Revisionsnummern haben sich beim Einspielen in das neue Repository geändert. Was ja auch logisch ist. Jedes Repository vergibt die Revisionsnummern von 0 aufwärts, wobei die Revisionsnummer ein Alleinstellungsmerkmal ist. Beim Zusammenlegen von zwei Repositories sind nun zwangsläufig die ersten x Revisionsnummern doppelt vergeben. Es sei denn eines oder gar beide Repositories enthalten keine Revisionen. Dann macht aber auch die ganze Übung hier keinen Sinn ;)

Dezentralisiertes Subversion Repository II

5 Januar 2009

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.

aptitude install svk

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 mdkir //mirror
svk mirror http://www.anrichter.net/svn/meinprojekt/trunk //mirror/meinprojekt_trunk
svk sync

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.

svk mkdir //local
svk copy //mirror/meinprojekt_trunk //local/meinprojekt_trunk

Die so angelegte lokale Kopie kann nun ausgeschleust werden.

mkdir -p ~/meinprojekt/trunk
cd ~/meinprojekt/trunk
svk co //local/meinprojekt_trunk

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.

cd ~/meinprojekt/trunk
svk commit

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.

svk pull
svk push

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

svn co file:///home/benutzer/.svk/local/local/meinprojekt_trunk ~/meinprojekt/trunk

Dezentralisiertes Subversion Repository

21 September 2008

Da ich nächste Woche für einige Tage ohne Netzwerk auskomme habe ich nach einer Möglichkeit gesucht, trotz allem in meine Subversion Repositories auf meinem Server zu committen. Es fehlt also die Möglichkeit ein Subversion Repository dezentral verwalten zu können, ähnlich Git. Git ist ursprünglich von Linus Torvalds entwickelt worden um BitKeeper als Quelltextverwaltung für den Linux-Kernel zu ersetzen. Das neue System zeichnet sich durch ein dezentralisiertes Quelltextmanagement aus. Jeder Entwickler hat eine lokale Kopie des Repositorys bzw. eines Zweiges aus dem Repository. Sämtliche Änderungen am Repository werden erst in die lokale Kopie eingespielt und später bei Bedarf und einer bestehenden Netzwerkverbindung mit einem Repository auf einem zentralen Server abgeglichen.

Diese Funktionalität vermisse ich derzeit noch bei Subversion. Aber dafür gibt es git-svn. Das Programm stellt eine Brücke zwischen dem lokal verwendeten Git und einem zentralen Subversion-Repository dar. Git-svn muss natürlich erst einmal auf dem Rechner installiert werden.

apt-get install git-svn

Danach lege ich mir ein leeres Verzeichnis für meinen lokalen Git-Klon an und besorge mir das Git-Repository aus meinem Subversion-Repository.

mkdir ~/src/meinprojekt/git/
cd ~/src/meinprojekt/git/
git-svn clone http://www.anrichter.net/svn/meinprojekt/trunk

Damit steht mir eine lokale Kopie meiner Quellen bereit. Dort kann ich weiter entwickeln und ganz ohne Netzwerkverbindung meine Änderungen in das Git-Repository einspielen.

git commit -a

Wenn ich später wieder Netzwerkverbindung habe, kann ich das Git-Repository von meinem Rechner mit dem Subversion-Repository auf meinem Server abgleichen. Dazu besorge ich mir erst alle Änderungen, die seit dem letzten Abgleich im Subversion-Repository erfolgt sind.

git-svn rebase

Danach kann ich meine eigenen Änderungen aus dem Git-Repository in das Subversion-Repository auf dem Server einspielen.

git-svn dcommit

Leider funktioniert das Vorgehen nicht mit externen Verweisen in einem Subversion Repository. Kann Git das Subversion-Property svn:external abbilden? Wenn ja wie? Oder geht das noch einfacher?

Neue Domain

16 Februar 2008

Seit gestern bin ich stolzer Besitzer einer neuen Domain. Ab sofort ist mein Blog und die Seiten von QSvn über http://www.anrichter.net erreichbar.

Bis auf weiteres werden Anfragen auf die alte Domain http://ar.oszine.de auf http://www.anrichter.net umgeleitet. Zu beachten ist der Zugriff auf das SVN-Repository von QSvn. Lokale Arbeitskopieen müssen erneut ausgeschleust werden, da SVN-Clients nicht ohne weiteres mit der Umleitung auf eine abweichende URL zurechtkommen.

Später, wenn sich die Wellen geglättet, alle Bookmarks aktualisiert sind und die Spider ihren Dienst verrichtet haben, wird die Subdomain ar.oszine.de vom Netz gehen.

WordPress per Subversion

27 Oktober 2007

Es gibt wieder eine neue Version von WordPress. Da ich Informatiker bin und diese Spezies Mensch bekanntermaßen von Haus aus faul ist, habe ich mich entschlossen, WordPress per Subversion zu installieren. Wie das geht? Lest selbst…
» Weiterlesen: WordPress per Subversion

Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Deutschland
This work by Andreas Richter is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Deutschland.