Die 5 wichtigen Neuerungen in Subversion 1.8

von Hubert Schmid vom 2014-02-16

Apache Subversion 1.8 wurde bereits vor über sechs Monaten veröffentlicht. Höchste Zeit also sich mit der neuen Version auseinanderzusetzen und die wichtigsten Neuerungen hervorzuheben. Zusammengefasst lässt sich sagen: Im Mittelpunkt der neuen Version stehen Verbesserungen bei der Usability, um die effiziente und effektive Verwendung von Subversion zu unterstützen. An den Kernfunktionen hat sich dagegen nur wenig geändert.

Complete Merge

In der Vergangenheit gab es von Entwicklern zahlreiche Beschwerden zu unerwarteten Merge-Konflikten. Bei genauerer Betrachtung zeigte sich jedoch, dass die meisten auf falsche Verwendung zurückzuführen sind, da viele Entwickler nicht zwischen Sync Merges und Reintegration Merges unterscheiden.

Seit Version 1.8 nimmt Subversion dem Entwickler diese Unterscheidung ab. Die beiden Verfahren wurden unter der Bezeichnung Complete Merge zusammengefasst, wobei Subversion automatisch zwischen Sync und Reintegration unterscheidet. Für Entwickler bedeutet es: Wer bisher schlechte Erfahrungen mit Merges gemacht und die Bedeutung der Option --reintegrate nicht ganz verstanden hat, wird überrascht sein, wie einfach und schnell Merges mit Subversion 1.8 funktionieren.

Merge Summary

Von Git hat sich Subversion die beliebten, Text-basierten Diagramme abgeschaut, um die Merge-History übersichtlich darzustellen. Während bei Git der Befehl git log --graph verwendet wird, setzt Subversion seit der Version 1.8 auf die Kommandozeile svn mergeinfo ^/trunk. Das letzte Argument steht für den Entwicklungszweig, der gegenüber dem aktuellen Branch dargestellt werden soll. Die Ausgabe ist nicht mit der von Git vergleichbar, da Subversion auf einem komplett anderen Branch-Konzept basiert. Der Zweck ist jedoch der Gleiche: Transparenz über den Status unterschiedlicher Entwicklungszweige erzeugen.

youngest common ancestor
    |         last full merge
    |         |        tip of branch
    |         |        |         repository path

    3                  8       
    |                  |       
  -------| |------------         trunk
     \          /              
      \        /               
       --| |------------         branches/feature
              |        |       
              6        8

Move Recordings

Bisher bildete Subversion die Umbenennung von Dateien durch eine Kombination aus Kopier- und Löschoperation ab. Was für die meisten Anwendungsfälle ausreichend ist, verursacht jedoch zahlreiche Merge-Konflikte, wenn andere Entwickler Dateien ändern, die im lokalen Arbeitsverzeichnis bereits umbenannt sind. Denn in diesem Fall ist unklar, was mit den Änderungen beim Update passieren soll.

Seit Version 1.8 speichert Subversion zusätzliche Informationen über umbenannte Dateien, und zeigt diese in der Ausgabe von svn stat an.

M       Jamroot
D       hello.cpp
        > moved to main.cpp
A  +    main.cpp
        > moved from hello.cpp

Aktualisiert man nun das Arbeitsverzeichnis und integriert die Änderungen anderer Entwickler, so werden sogenannte Tree Conflicts für umbenannte Dateien automatisch aufgelöst. Dazu muss bei dem interaktiven Aufruf lediglich die Option mc (mine-conflict) ausgewählt werden.

Updating '.':
   C hello.cpp
At revision 9.
Tree conflict on 'hello.cpp'
   > local file moved away, incoming file edit upon update
Select: (mc) apply update to move destination, (p) postpone,
        (q) quit resolution, (h) help: mc
U    main.cpp
Updated to revision 9.
Resolved conflicted state of 'hello.cpp'
Summary of conflicts:
  Tree conflicts: 0 remaining (and 1 already resolved)

Repository Dictated Configuration

Subversion kennt bis Version 1.7 zwei Arten von Einstellungen: Die Runtime Configuration ist spezifisch für jeden Benutzer und wirkt sich auf alle Projekte aus. Die Directory Properties werden dagegen im Repository gespeichert, gelten für alle Benutzer und beschränken sich auf genau ein Verzeichnis.

Subversion 1.8 führt darüber hinaus nun endlich auch Projekt-spezifische Konfigurationseinstellungen ein, die im Repository gespeichert werden und für alle Benutzer gelten. Dabei ist mit Projekt ein kompletter Verzeichnisbaum gemeint, der typischerweise dem Softwaremodul entspricht. Einstellungen können jedoch für beliebige Verzeichnissen definiert werden, und erstrecken sich stets über die Hierarchie.

Die beiden wichtigsten Properties sind svn:global-ignores und svn:auto-props, die den entsprechenden Einstellungen aus der Runtime Configuration entsprechen. Das folgende Listing zeigt, wie die beiden Properties von der Kommandozeile aus gesetzt werden können.

$ svn propset svn:global-ignores '*.o' .
$ svn propset svn:auto-props '*.bat = svn:eol-stype=CRLF;svn:executable' .

Log Search

Das Commit-Protokoll ist in vielen Projekten eine wichtige Informationsquelle, um Änderungen nachvollziehen zu können. Um dieses zu durchforsten war man bei Subversion bisher auf externe Programme angewiesen – beispielsweise indem man die Ausgabe von svn log mittels grep filterte. Nun kann Subversion auch selbst filtern, was den Use-Case deutlich vereinfacht. Dafür nutzt man die Optionen --search und --search-and. Sie unterstützen Muster und einfache logische Verknüpfungen.

Der folgende Befehl durchsucht beispielsweise die komplette Historie nach Log-Einträgen, die mittels Tags auf Issues verweisen. Zu beachten ist, dass Subversion nur die Attribute durchsucht, die auch angezeigt werden. Oder in anderen Worten: Über die beiden Optionen -q und -v lässt sich die Suche auf Meta-Informationen einschränken oder auf Dateipfade ausweiten.

$ svn log --search 'FOOBAR-[0-9]'

Alle beschriebenen Erweiterungen sind mit der Client-Software ab Version 1.8 nutzbar. Auf dem Server ist dagegen keine Aktualisierung erforderlich – allerdings kann sie die Performance einiger Operationen signifikant verbessern. Einer Nutzung der Neuerungen steht demnach nichts im Wege. Auf zur Version 1.8!