Ich habe bei mir in der Firma letzte Nacht sämtliche unserer SVN-Repositories vom SVN-Server unserer ehemaligen Mutterfirma auf unsereren eigenen migriert.
Knapp 14GB Daten an SVN-Dumps und gut 50 Repositories.
Was ich dabei gelernt habe war:
0. Die alten Repository-URLs per mod_rewrite auf die neuen Umzulenken war eine gute Idee und klappt problemlos. Auch wenn an 2 Stellen an der URL herumgeschrieben werden muss und das ganze von extern nach intern über eine ProxyPass und ProxyPassReverse-Direktive laufen muss.
1. PROPFIND vergessen zu definieren eine blöde Idee. Man erhält so wünderschöne Fehlermeldungen wie:
“Repository moved temporarily to $NEUER_PFAD please relocate”, wobei $NEUER_PFAD bereits der Pfad ist, unter dem das Repository dann letzten Endes nach der Umstellung auch liegt. TortoiseSVN konnte bei einem Relocate lediglich die Repository-Konfig nicht einlesen und verweigert somit die Umstellung..
Ein simples
<Limit PROPFIND>
Require valid-user
<Limit>
in Directory-Container für das SVN-Verzeichnis in der Vhost-Konfig behob dann das Problem.
3. Wenn Entwickler mit SVN nicht umzugehen wissen ist das blöd. Wir hatten ein Repository mit knapp 17.893 Commits. Es war aber nur 50MB groß. (Das sind nur 2,86 KB pro Commit!)
Des Rätsels Lösung?
Es wurden erst knapp 30MB an .xml-Dateien eingecheckt, dann mit dem nächsten Commit wieder gelöscht. Dann wieder eingecheckt usw. Nur ganz selten wurde mal eine .xml-Datei geändert.
Subversion hat dann immer brav alles eingespielt, wieder gelöscht usw.
Hat knapp 45min gedauert das Repository einzuspielen..
4. Sämtliche Gruppen-, Repository- und Benutzernamen ein jeweils eigenes Namensschema zu geben und die groups und htpasswd Dateien alphabetisch sortieren zu lassen war auch eine gute Idee.
Man findet sich auf Anhieb wieder zurecht :-)
Ich habe die Repositorynamen jetzt immer Kleingeschrieben und die Gruppen des Repositories heißen wie das Repository. Wenn keine Lese-/Schreibrechte vorhanden sind, werden die Rechte durch Unterstrich getrennt auch im Gruppennamen deutlich.
Wird Pfad-basierte Authentifizierung verwendet, werden die Pfad direkt nach dem Root-Verzeichnis des Repositories festgelegt.
Also z.B.:
[repo1:/]
@repo1 = rw
@repo1_read = r
[repo1:/Dokumentation]
@repo1 = rw
@repo1_read =
Wie das vorher aussah will man nicht wissen :-)
Tags: apache, migration, mod_rewrite, subversion
Hallo,
ich habe gerade eine ähnliche Situation. Wir hatten ein SVN-Repository (ja, eins!) unter http://alterserver/svn. Dieses sollte auf einen neuen Server umgezogen, wo mit multiplen Repos gearbeitet wird, in ein eigenes Repo. So: http://neuerserver/svn/alt
Da viele Leute viele Pfade ausgecheckt hatten, wollte ich es ihnen ersparen, hunderte Male ein svn switch –relocate durchzuführen. Also kam ich auch auf die mod_rewrite-Idee. Leider funktioniert es bei mir nicht so ganz.
Geht man im Webbrowser auf die alte oder die neue URL, sind sie gleich. Die Rewrite Rules scheinen also prinzipiell zu funktionieren. Nur wenn ich es per Kommandozeile bzw. SVN-Client probiere, bekomme ich die Fehlermeldung svn: ‘/svn/alt/!svn/vcc/default’ path not found
Im Apache-Access-Log sehe ich auch, dass dieser Pfad angefordert und mit 404 quittiert wird. Führe ich den gleichen SVN-Befehl (hier war es svn info) allerdings auf den neuen Pfad aus, wird laut log exakt die gleiche Datei angefordert, diesmal klappt es allerdings.
Ich kann mir das nicht so ganz erklären, vielleicht mag SVN meine Rewrite Rules nicht. Könntest Du so nett sein, und mir mal Deine Apache-Konfig für das SVN samt Rewrite Rules posten? Das wäre mir eine große Hilfe.
Vielen Dank & Gruß, Jay