Wer mit Subversion arbeitet wir sich sicher schon gefragt haben wie man die .svn Verzeichnisse aus allen Unterordner loswerden kann. Dies ist vor allem bei Webseiten ein Thema, wo die ganze Seite mit all ihren Unterverzeichnissen möglichst 1:1 auf den Webserver soll.
In der Regel werden die meisten Leute eine dieser beiden Ansätze verfolgen:
- Alle .svn Ordner von Hand löschen
- Die .svn Ordner drin lassen und hoffen das es niemand bemerkt
Der erste Ansatz ist aufwendig und wird innert kürzester Zeit für den zweiten Ansatz fallen gelassen. Das sollte man aber nicht tun.
Wieso .svn Verzeichnisse nicht ins Web gehören
In den .svn Ordnern liegen sehr viele Daten die man nicht unbedingt über einen Webserver der Öffentlichkeit freigeben möchte. Subversion legt intern eine Kopie aller unter Versionsverwaltung stehenden Dateien an und legt diese im .svn Ordner ab. Kennt man sich ein bisschen mit der Ablagestruktur aus kann man recht einfach den Quellcode einer PHP oder ASP.Net Seite kommen. Vom abkupfern der Funktionalität zum stehlen DB-Passworts ist es dann oft nur ein kleiner Schritt. Die Metadaten von Subversion müssen also auf eine einfache Art entfernt werden.
svn export
Subversion hat für diese Aufgabe den Befehl export. Dieser funktioniert fast wie checkout, räumt aber all die .svn Verzeichnisse weg. Die so erhaltene Kopie beinhaltet nichts mehr was auf Subversion schliessen lässt – ein commit der Änderungen ist damit aber auch nicht mehr möglich!
So kann man den export Befehl aufrufen:
svn export https://svn.origo.ethz.ch/ataraxis/ ataraxisExport
Verfügt man bereits über eine lokale Arbeitskopie (mit allen .svn Verzeichnissen), kann man auch diese als Quelle nutzen:
svn export ataraxis ataraxisOhneSvnOrdner
Fazit
Mit dem simplen Befehl svn export kann man ohne grossen Aufwand die lästigen .svn Verzeichnisse vor der Veröffentlichung entfernen.
Bei den Abklärungen zum Umzug von AtaraxiS habe ich mich mit dem Kopieren des Subversion Repository beschäftigt. Dabei fand ich 2 Varianten, die je nach Situation verwendet werden können.
Kopieren mittels svnadmin
Der einfachste Weg ein Subversion Repository zu kopieren ist das erstellen eines Dump mittels svnadmin. Dieser kann danach ins neue Repository importiert werden. Der Umzug der Daten von RepoA ins neue RepoB kann so durchgeführt werden:
svnadmin dump RepoA > RepoA.dump
svnadmin create RepoB; svnadmin load RepoB < RepoA.dump
Diese Lösung ist der empfohlene Weg. Allerdings muss svnadmin dazu auf dem Server ausgeführt werden, auf dem das Repository liegt. Fehlt einem der Zugang zum Server, ist dieser Ansatz nicht umsetzbar.
Kopieren mittels svnsync
Kann man svnadmin nicht verwenden, kann gibt es noch eine andere Möglichkeit. Sofern das Repository nicht all zu alt ist (1.4 oder neuer) kann man svnsync verwenden. Im Blog Paul’s Journal fand ich eine praktische Anleitung, die ich hier leicht abgeändert wiedergebe.
Der Ablauf für diese Art des Kopierens ist ein wenig umfangreicher:
export TOREPO=RepoB
mkdir $TOREPO
svnadmin create $TOREPO
cd $TOREPO
cat > hooks/pre-revprop-change <<EOF
#!/bin/sh
EOF
chmod 755 hooks/pre-revprop-change
cd ..
svnsync init file:///home/jgr/tmp/$TOREPO https://ein.entfernter.Server/repos/RepoA
svnsync --non-interactive sync file:///home/jgr/tmp/$TOREPO
svnadmin dump $TOREPO > {$TOREPO}.dump
Erst wird ein leeres Repository erstellt. Um ein wenig flexibler zu sein, ist der Namen des Zielrepository als Variable TOREPO definiert. Svnsync benötigt das Hookscript pre-revprop-change, das in dem Fall hier nichts machen soll. (Unter Windows genügt dafür eine leere *.bat Datei)
Ist das Repository bereit, kann man svnsync initialisieren und danach mit der Synchronisierung beginnen. Je nach Netzverbindung und Grösse des Repository kann dieser Vorgang einige Zeit dauern.
Am Ende empfiehlt es sich einen Dump zu erstellen. So braucht man beim nächsten Anlauf nicht wieder alle Daten übers Netzt zu kopieren.
Weitere Informationen
Wer gerne noch mehr zu dem Thema wissen möchte, sollte sich das SVN Buch von Red Bean anschauen. Auch die Kommentare zum Blogeintrag von Paul sollte man sich anschauen.
Kategorien:SVN
Schlagworte: SVN
Letzte Woche kam eine interessante Frage auf: welche Version bekommt man in SVN, wenn man auf ein Tag wechselt, auf dies jemand einen Commit ausführte? Ist es die Version bei der man den Tag erstellte oder die letzte Änderung darin?
Bekommt man in der Situation Revision 2 oder 3?
Ein wenig über die Begriffe
SVN ist ein Tool zur Versionierung von Dateien (Sourcecode, Texte, Bilder, usw.).
Mit Hilfe von Tags können in SVN spezifische Versionsstände mit einem eindeutigen Namen markiert werden. Als Beispiel kann die Übergabe der Entwicklung an die Tester mit “v1.0.2_to_test” markiert werden. Dieser Name ist einfacher zu merken als die Revisionsnummer 13478.
Ein Branch ist ein Entwicklungszweig. Dieser läuft getrennt vom Trunk, der Hauptentwicklung. Branches kann man zur Versionswartung nutzen. Hat man seine Version 1 veröffentlicht und findet während der Arbeit an Version 2 einen Bug in v1, kann man den Branch nutzen um auf der Code-Basis von v1 den Fehler zu beheben. Dazu wechselt man vom Trunk in den Branch, macht seine Änderung und committed diese in den Branch. Wikipedia hat dazu noch mehr.
Zurück zur Frage
Was passiert nun, wenn man auf den Tag wechselt und dort eine Änderung committed? Man also ein Tag als Branch benutzt?
Intern macht SVN selber keinen Unterschied zwischen einem Tag und einem Branch. Je nach SVN-Client bekommt man aber vor dem commit eine Warnung:
TortoiseSVN warnt vor commit auf ein Tag
Hat man dann aber erst einmal den commit ausgeführt, gibt es keinen Unterschied mehr zwischen Tag und Branch. Diese liegen dann – je nach gewählter Struktur – nur in unterschiedlichen Verzeichnissen.
Ein Update auf den Tag bringt einem somit die letzte Version von diesem „Branch“. Wenn man sich also den Aufwand macht und getrennte Verzeichnisse für Tags und Branches nutzt, sollte man dann auch entsprechend damit arbeiten: Also keine commits auf einen Tag.
