Tag Archives: Subversion

Farbige, seitenweise Diffs mit Mercurial

Bei der Mitarbeit an verschiedenen Projekten ist man heutzutage beinahe schon gezwungen sich mit verschiedenen Versionsverwaltungssystemen auseinanderzusetzen. Ich selbst benutze am liebsten Mercurial, aber es gibt auch Projekte, wo Git oder Subversion benutzt werden. Alle haben ihre Vor- und Nachteile aber so gewisse Dinge, die das eine per default macht, hätte man gern auch im anderen und bei einigen Dingen bekommt man das sogar hin.

Ein wirklich praktisches Feature von Git ist beispielsweise, dass es bei einem git diff den Output farbig und im Pager darstellt. Um dieses Verhalten in Subversion nutzen zu können, kann man ein externes Skript nutzen, das ich letztens im Netz gefunden habe: Color highlighted diffs with git, svn and cvs. Für Mercurial hab ich mich gerade nochmal selbst auf die Suche gemacht und folgende Lösung gefunden:

Im Grunde muss man nur die beiden Erweiterungen color und pager aktivieren und konfigurieren. Das sieht bei mir in der ~/.hgrc jetzt wie folgt aus:

Die Aktivierung der Extensions ist selbsterklärend, die Optionen habe ich so von der Wikiseite zur pager-Extension übernommen bzw. über man less nochmal nachgelesen. Wichtig hier ist auf jeden Fall das ‘R’, damit die Farbcodes von less auch interpretriert werden.

Automatische Keyword-Ersetzung mit Mercurial

In der Diskussion zu CRE130 über verteilte Versionsverwaltungssysteme kam die Frage auf, ob man Mercurial für die Bearbeitung von LaTeX-Files nutzen und dort dann vielleicht sogar eines der Pakete rcs, rcsinfo, rcs-multi, svn, svninfo, svn-multi oder vc verwenden kann. Ersteres ist kein Problem. Selbstverständlich kann man mit Mercurial seine LaTeX-Dokumente versionieren.

Die automatische Ersetzung von sogenannten Keywords, wie man das von RCS, CVS oder Subversion kennt, lässt sich bei Mercurial über die Erweiterung Keyword Extension realisieren, die bei Mercurial gleich dabei ist. Damit das möglicherweise mit einem der oben genannten LaTeX-Pakete zusammenspielt, beschreibe ich nun, wie man die Keywords denen von Subversion maximal ähnlich aussehen lässt.

Zunächst muss man die Erweiterung aktivieren. Das macht man am besten nicht global sondern einzeln im Repository, indem man im Repo in die Datei .hg/hgrc folgendes einfügt:

Auf welche Dateien die automatische Ersetzung angewendet wird, bestimmt man in einem weiteren Abschnitt, hier z.B. für alle Dateien mit der Endung .txt in allen Unterordnern des Repositorys:

Die Ausgestaltung der Keywords kann man nun mit der Template Engine (in anderem Zusammenhang in Kapitel »Customizing the output of Mercurial« des großartigen Mecurial Buchs beschrieben) von Mercurial selbst vornehmen. Es gibt zwar default Keywords, aber in der .hg/hgrc definiert man die besser selbst. Meine aktuellen Einstellungen sehen wie folgt aus:

In einer Testdatei führt das dann zu folgendem Ergebnis bei der Ersetzung:

Um das dem Output von Subversion noch ähnlicher zu machen, könnte man den Teil für die Revision sogar noch auf {rev} abkürzen. Hier ist allerdings zu beachten, dass die Revisionsnummern von Mercurial nicht global eindeutig sind, sondern nur für das jeweilige Repository gelten.

HowTo: Migration von Subversion Repositories mit eisfair

eisfair-2 steht vor der Tür, ich erwähnte es bereits im letzten Jahr und auch dieses Jahr anlässlich des LinuxTag. Da es kein Upgrade von eisfair-1 auf eisfair-2 geben wird, muss man die Kiste mehr oder weniger von Hand migrieren. Wie man seine Subversion-Repositories umzieht, beschreibe ich in diesem Artikel.

Falls aktiv und häufig mit den Repositorys gearbeitet wird, sollte der erste Schritt darin bestehen, die Schreibrechte auf dem alten Server zu entziehen. Das einfachste ist, in der Subversion-Konfiguration die Variablen SVN_REPOS_?_ANON_ACCESS und SVN_REPOS_?_AUTH_ACCESS für das umzuziehende Repository auf ‘read’ oder auf ‘none’ zu setzen.

Dann folgt das Backup des alten Repositorys. Dies sollte man an dieser Stelle manuell anstoßen, weil man nicht sicher sein kann, dass nicht noch jemand nach dem letzten automatischen Backup was eingecheckt hat. Dazu wählt man im Setup-Menü den entsprechenden Punkt für das Backup und im folgenden Dialog aus einer Liste das entsprechende Repository. Danach läuft der Dump vom Repository durch. Wenn das abgeschlossen ist, wird beim Subversion Paket ab 0.5.0 dann der Pfad und Name vom soeben erstellten Backup angezeigt, den man sich merken sollte, um zu wissen, welche Datei man gleich auf den Zielrechner zu kopieren hat. Bei älteren Paketversionen muss man im Setup-Menü nochmal den Menüpunkt ‘List backup files’ auswählen. Das grad erstellte Backup steht wahrscheinlich ganz oben, im Zweifelsfall schaut man auf Datum und Uhrzeit, die im Dateinamen mit drin stehen.

Der nächste Schritt besteht darin, die Backupdatei auf den Zielrechner zu kopieren, auf dem man bereits das Subversion-Paket installiert hat. Um das Backup über das Setup-Menü wieder einspielen zu können, muss der Zielpfad für die Kopieraktion der in SVN_BACKUP_TARGET angegebene sein. Außerdem sollte man ein neues leeres Repository einrichten, in das gleich das Backup eingespielt wird.

Aus dem Setup-Menü des Subversion-Pakets wählt man dann den Punkt ‘Restore repository’. Aus der Liste wählt man das soeben neu erstellte leere Repository. Das war es schon. Jetzt nur noch den Nutzern die neue Adresse mitteilen und fröhlich mit dem umgezogenen Repository weiter arbeiten. Das ganze nochmal in Kürze:

  • altes Repo auf dem Quellrechner deaktivieren oder wenigstens die Schreibrechte entziehen, nicht löschen natürlich!
  • setup -> Administration of services -> subversion administration -> Subversion Administration Tools -> Subversion backup and restore -> Backup repository
  • gewünschtes Repo auswählen
  • bei Paket vor 0.5.x: List backup files, entsprechende Datei steht wahrscheinlich ganz oben, auf die Zeit achten, um von cron-generierten zu unterscheiden, hier: /mnt/data2/backup/svn/repos1-2008-09-24-095600.backup.bz2
  • ansonsten angezeigten Dateinamen des Backup kopieren
  • auf den Zielrechner kopieren in das Verzeichnis was dort bei SVN_BACKUP_TARGET angegeben ist
  • neues Repo anlegen auf Zielrechner
  • Restore repository: richtiges Backup-File aus der Liste wählen
  • das neu erstellte Repo aus der Liste wählen