Ebenso wie Subversion Eigenschaften verwendet, um zusätzliche Informationen über die enthaltenen Dateien, Verzeichnisse und Revisionen zu speichern, könnten Eigenschaften auch für Sie ähnlich von Nutzen sein. Sie werden es vielleicht als nützlich ansehen, wenn Sie in der Nähe Ihrer versionierten Daten spezielle Metadaten dazu unterbringen können.

Nehmen wir mal an, Sie möchten eine Webpräsenz entwerfen, die viele digitale Fotos mit Bildunterschrift und Zeitstempel anzeigen soll. Da sich die Menge Ihrer Fotos ständig ändert, möchten Sie soviel wie möglich automatisieren. Die Fotos können ziemlich groß werden, so dass Sie den Besuchern Ihrer Seite Miniaturvorschaubilder anbieten möchten.

Natürlich können Sie diese Funktionalität auch mit herkömmlichen Dateien hinbekommen. Das bedeutet, Sie haben image123.jpg und image123-thumbnail.jpg gemeinsam in einem Verzeichnis. Oder Sie speichern die Vorschaubildchen in einem anderen Verzeichnis, etwa thumbnails/image123.jpg, falls Sie die gleichen Dateinamen beibehalten möchten. Sie können auch die Bildunterschriften und Zeitstempel auf ähnliche Weise speichern, ebenso vom Originalbild getrennt. Das Problem hierbei ist jedoch, dass sich Ihre Ansammlung an Dateien mit jedem neu hinzugefügten Bild vervielfältigt.

Betrachten Sie nun dieselbe Webpräsenz, eingerichtet unter Verwendung der Datei-Eigenschaften von Subversion. Stellen Sie sich vor, sie hätten eine einzelne Bilddatei image123.jpg mit Eigenschaften namens Unterschrift, Zeitstempel und sogar Vorschaubild. Jetzt sieht Ihr Verzeichnis viel überschaubarer aus – tatsächlich sieht es für den flüchtigen Betrachter aus, als befänden sich dort nur Bilddateien. Ihre Automatisierungs-Skripte wissen es jedoch besser. Sie wissen, dass sie svn verwenden können (oder noch besser, die Subversion-Sprachschnittstellen – siehe „Benutzung der APIs“), um die von Ihrer Webpräsenz zusätzlich benötigten Informationen herauszuholen, ohne eine Indexdatei lesen oder Pfad-Umbenennungs-Spielereien machen zu müssen.

Anmerkung

Obwohl Subversion kaum Einschränkungen für die von Ihnen verwendeten Namen und Werte für Eigenschaften macht, ist es nicht entworfen worden, um optimal mit großen Eigenschafts-Werten oder umfangreichen Eigenschafts-Mengen für eine bestimmte Datei oder ein Verzeichnis umgehen zu können. Gewöhnlich behält Subversion gleichzeitig alle Eigenschafts-Namen und -Werte im Speicher, die zu einem einzelnen Objekt gehören, was bei umfangreichen Eigenschafts-Mengen zu erheblichen Leistungseinbußen oder fehlgeschlagenen Operationen führen kann.

Spezielle Revisions-Eigenschaften werden auch sehr oft genutzt. Häufig wird eine Eigenschaft verwendet, deren Wert eine Fehlernummer eines Fehlerverwaltungssystem ist, mit dem die Revision in Beziehung gebracht wird, etwa weil eine mit dieser Revision vorgenommene Änderung den entsprechenden Fehler behebt. Andere Anwendungsfälle umfassen die Vergabe anwenderfreundlicher Namen für die Revision – es könnte schwierig sein, sich zu erinnern, dass Revision 1935 vollständig getestet war. Wenn es jedoch eine Eigenschaft Testergebnis mit dem Wert alles bestanden für diese Revision gibt, ist das eine durchaus nützliche Information. Subversion erlaubt es Ihnen auf einfache Weise mit der Option --with-revprop des Befehls svn commit:

$ svn commit -m "Fix up the last remaining known regression bug." \
             --with-revprop "test-results=all passing" 
Sende          lib/crit_bits.c
Übertrage Daten .
Revision 912 übertragen.
$

$ svn log --with-all-revprops --xml lib/crit_bits.c
<?xml version="1.0"?>
<log>
<logentry
   revision="912">
<author>harry</author>
<date>2011-07-29T14:47:41.169894Z</date>
<msg>Fix up the last remaining known regression bug.</msg>
<revprops>
<property
   name="testresults">all passing</property>
</revprops>
</logentry>
…
$

Issue(s): IZ2376, IZ1919
Reviewed by:  sally

This fixes a nasty segfault in the wort frabbing process
…

Das Programm svn gestattet es, Datei- und Verzeichnis-Eigenschaften auf verschiedene Weise hinzuzufügen oder zu ändern. Für Eigenschaften mit kurzen menschenlesbaren Werten ist es vermutlich am einfachsten, eine neue Eigenschaft zu vergeben, indem deren Name und Wert auf der Kommandozeile für den Unterbefehl svn propset angegeben wird:

$ svn propset copyright '(c) 2006 Red-Bean Software' calc/button.c 
Eigenschaft »copyright« für »calc/button.c« gesetzt
$

Jedoch haben wir die von Subversion angebotene Flexibilität bei der Behandlung Ihrer Eigenschafts-Werte angepriesen; und wenn Sie planen, einen mehrzeiligen textuellen oder sogar binären Eigenschafts-Wert zu verwenden, wollen Sie diesen wahrscheinlich nicht auf den Kommandozeile angeben. Deshalb besitzt der Unterbefehl svn propset eine Option --file (-F), um den Namen einer Datei angeben zu können, deren Inhalt den neuen Eigenschafts-Wert ergibt.

$ svn propset license -F /path/to/LICENSE calc/button.c 
Eigenschaft »license« für »calc/button.c« gesetzt
$

Es gibt einige Einschränkungen für die Vergabe von Namen für Eigenschaften. Ein Eigenschafts-Name muss mit einem Buchstaben, einem Doppelpunkt (:) oder einem Unterstrich (_) beginnen; danach können Sie auch Ziffern, Bindestriche (-) und Punkte (.) verwenden.^[13]

Zusätzlich zum Befehl propset bietet das Programm svn den Befehl propedit. Dieser Befehl verwendet den konfigurierten Editor (siehe „Allgemeine Konfiguration“), um Eigenschaften hinzuzufügen oder zu ändern. Wenn Sie den Befehl aufrufen, startet svn Ihren Editor mit einer temporären Datei, die den gegenwärtigen Wert der Eigenschaft beinhaltet (oder leer ist, falls Sie eine neue Eigenschaft hinzufügen). Dann bearbeiten Sie diesen Wert in Ihrem Editor bis er dem Wert entspricht, den Sie für die Eigenschaft verwenden möchten, speichern die Datei und beenden den Editor. Falls Subversion feststellt, dass Sie tatsächlich den bestehenden Wert der Eigenschaft geändert haben, wird das als neuer Wert angenommen. Wenn Sie Ihren Editor ohne Änderungen beenden, wird die Eigenschaft nicht verändert:

$ svn propedit copyright calc/button.c  ### den Editor ohne Änderungen verlassen
Keine Änderungen der Eigenschaft »copyright« für »calc/button.c«
$

Hier sollten wir anmerken, dass die svn-Unterbefehle, die mit Eigenschaften zu tun haben, ähnlich wie bei anderen Unterbefehlen, auch auf mehrere Pfade gleichzeitig angewendet werden können. Das ermöglicht Ihnen, mit einem Befehl die Eigenschaften auf einer Menge von Dateien zu bearbeiten. Wir hätten beispielsweise das Folgende machen können:

$ svn propset copyright '(c) 2006 Red-Bean Software' calc/* 
Eigenschaft »copyright« für »calc/Makefile« gesetzt
Eigenschaft »copyright« für »calc/button.c« gesetzt
Eigenschaft »copyright« für »calc/integer.c« gesetzt
…
$

Das ganze Hinzufügen und Bearbeiten von Eigenschaften ist nicht gerade nützlich, falls an die gespeicherten Werte nicht einfach heranzukommen ist. Also bietet das Programm svn zwei Unterbefehle zur Anzeige der Namen und Werte von Eigenschaften an Dateien und Verzeichnissen. Der Befehl svn proplist listet alle Eigenschafts-Namen auf, die für einen Pfad vergeben sind. Sobald Sie die Eigenschafts-Namen auf einem Element kennen, können Sie die Werte einzeln mittels svn propget abrufen. Wenn diesem Befehl ein Eigenschafts-Name und ein Pfad (oder eine Menge von Pfaden) mitgegeben wird, wird der Wert der Eigenschaft nach Standardausgabe geschrieben.

$ svn proplist calc/button.c 
Eigenschaften zu »calc/button.c«:
  copyright
  license
$ svn propget copyright calc/button.c
(c) 2006 Red-Bean Software

Es gibt sogar eine Variante des Befehls proplist, die es erlaubt, sowohl die Namen als auch die Werte aller Eigenschaften auszugeben. Übergeben Sie einfach die Option --verbose (-v).

$ svn proplist -v calc/button.c 
Eigenschaften zu »calc/button.c«:
  copyright
    (c) 2006 Red-Bean Software
  license
    ================================================================
    Copyright (c) 2006 Red-Bean Software.  All rights reserved.

    Redistribution and use in source and binary forms, with or without
    modification, are permitted provided that the following conditions 
    are met:

    1. Redistributions of source code must retain the above copyright
    notice, this list of conditions, and the recipe for Fitz's famous
    red-beans-and-rice.
    …

Der letzte Unterbefehl, der mit Eigenschaften zu tun hat, ist propdel. Da Subversion Eigenschaften mit leeren Werten erlaubt, können Sie eine Eigenschaft nicht vollständig mit svn propedit oder mit svn propset entfernen. So hat beispielsweise dieser Befehl nicht den erwünschten Effekt:

$ svn propset license "" calc/button.c 
Eigenschaft »license« für »calc/button.c« gesetzt
$ svn proplist -v calc/button.c
Properties on 'calc/button.c':
  copyright
    (c) 2006 Red-Bean Software
  license

$

Zum vollständigen Löschen von Eigenschaften müssen Sie den Unterbefehl propdel verwenden. Die Syntax ist den anderen Eigenschafts-Befehlen ähnlich:

$ svn propdel license calc/button.c 
Eigenschaft »license« wurde von »calc/button.c« gelöscht.
$ svn proplist -v calc/button.c 
Eigenschaften zu »calc/button.c«:
  copyright
    (c) 2006 Red-Bean Software
$

Können Sie sich an diese unversionierten Revisions-Eigenschaften erinnern? Auch diese können Sie mit den eben beschriebenen Unterbefehlen von svn verändern. Geben Sie einfach den Kommandozeilenparameter --revprop an und die Revision, deren Eigenschaft Sie ändern möchten. Da Revisionen global sind, brauchen Sie keinen Zielpfad für diese Eigenschafts-Unterbefehle anzugeben sofern Sie sich in einer Arbeitskopie des Projektarchivs befinden, deren Revisions-Eigenschaft Sie ändern möchten. Anderenfalls können Sie den URL irgendeines Pfades im entsprechenden Projektarchiv angeben (inklusive des Wurzelverzeichnisses des Projektarchivs). Sie möchten beispielsweise die Protokollnachricht einer bestehenden Revision ändern.^[14] Falls Ihr aktuelles Arbeitsverzeichnis Teil einer Arbeitskopie Ihres Projektarchivs ist, können Sie einfach den Befehl svn propset ohne Zielpfad aufrufen:

$ svn propset svn:log "* button.c: Fix a compiler warning." -r11 --revprop 
Eigenschaft »svn:log« wurde für Revision »11« im Projektarchiv gesetzt
$

Selbst wenn Sie keine Arbeitskopie aus diesem Projektarchiv ausgecheckt haben, können Sie dennoch die Änderung an der Eigenschaft durchführen, indem Sie den URL der Wurzel des Projektarchivs angeben:

$ svn propset svn:log "* button.c: Fix a compiler warning." -r11 --revprop \
              http://svn.example.com/repos/project 
Eigenschaft »svn:log« wurde für Revision »11« im Projektarchiv gesetzt.
$

Beachten Sie, dass die Fähigkeit, diese unversionierten Eigenschaften zu verändern, ausdrücklich vom Administrator des Projektarchivs hinzugefügt werden muss (siehe „Berichtigung des Protokolleintrags“). Das geschieht aus dem Grund, dass diese Eigenschaften nicht versioniert sind, und Sie Gefahr laufen, durch unvorsichtiges Bearbeiten Informationen zu verlieren. Der Administrator des Projektarchivs kann Schutzmaßnahmen gegen diesen Verlust ergreifen, und standardmäßig ist die Veränderung unversionierter Eigenschaften nicht freigeschaltet.

Tipp

Benutzer sollten nach Möglichkeit svn propedit statt svn propset verwenden. Während das Endergebnis dieser Befehle identisch ist, wird bei ersterem der aktuelle Wert der zu ändernden Eigenschaft angezeigt, was dabei hilft, sicherzustellen, dass die Änderung auch die beabsichtigte war. Das gilt besonders für unversionierte Revisions-Eigenschaften. Darüber hinaus ist es auch bedeutend einfacher, mehrzeilige Eigenschafts-Werte in einem Texteditor statt auf der Kommandozeile zu bearbeiten.

Jetzt, da Sie mit allen svn-Unterbefehlen vertraut sind, die mit Eigenschaften zu tun haben, wollen wir uns ansehen, welche Auswirkungen Änderungen an Eigenschaften auf den üblichen Arbeitsablauf von Subversion haben. Wie wir bereits früher erwähnten, sind Eigenschaften von Dateien und Verzeichnissen versioniert, genau so wie der Dateiinhalt. Deshalb bietet Subversion dieselben Möglichkeiten für das Zusammenführen der Änderungen anderer mit Ihren eigenen – sauber oder konfliktbehaftet.

Wie bei Dateiinhalten handelt es sich bei Ihren Eigenschafts-Änderungen um lokale Modifikationen, die erst dann dauerhaft werden, wenn Sie sie mittels svn commit an das Projektarchiv übertragen. Ihre Eigenschafts-Änderungen können auch leicht rückgängig gemacht werden – der Befehl svn revert bringt Ihre Dateien und Verzeichnisse wieder in den unbearbeiteten Zustand – und zwar Inhalt, Eigenschaften und alles andere. Auch können Sie durch die Benutzung der Befehls svn status und svn diff interessante Informationen über den Status Ihrer Datei- und Verzeichnis-Eigenschaften erhalten.

$ svn status calc/button.c
 M      calc/button.c
$ svn diff calc/button.c 
Eigenschaftsänderungen: calc/button.c
___________________________________________________________________ 
Hinzugefügt: copyright
## -0,0 +1 ##
+(c) 2006 Red-Bean Software
$

Beachten Sie, dass der Unterbefehl status das M in der zweiten statt in der ersten Spalte anzeigt. Das geschieht, da wir zwar die Eigenschaften von calc/button.c verändert haben, nicht jedoch dessen Inhalt. Hätten wir beides geändert, würden wir M auch in der ersten Spalte sehen. (svn status behandeln wir in „Verschaffen Sie sich einen Überblick über Ihre Änderungen“).

$ svn update calc
Aktualisiere »calc«:
M  calc/Makefile.in 
Konflikt für Eigenschaft »linecount« für »calc/button.c« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (h) Hilfe für weitere Optionen: p
 C calc/button.c
Aktualisiert zu Revision 143.
Konfliktübersicht:
  Eigenschaftskonflikte: 1
$ 

$ svn status calc
 C      calc/button.c
?       calc/button.c.prej
$ cat calc/button.c.prej 
Versuch, die Eigenschaft »linecount« von »1267« in »1301« zu ändern,
aber die Eigenschaft wurde lokal von »1267« in »1256« geändert.
$

Ihnen ist vielleicht auch die ungewöhnliche Art und Weise aufgefallen, wie Subversion momentan Unterschiede von Eigenschaften darstellt. Sie können immer noch svn diff verwenden und dessen Ausgabe umleiten, um eine Patch-Datei zu erzeugen. Das Programm patch ignoriert Patches für Eigenschaften – es ignoriert regelmäßig alles, was es nicht versteht. Das bedeutet leider, dass für die vollständige Anwendung eines durch svn diff erzeugten Patches mit patch sämtliche Änderungen an Eigenschaften manuell nachgezogen werden müssen.

Subversion 1.7 verbessert diese Situation auf zweierlei Weise. Zunächst ist seine nicht-standardmäßige Anzeige von Eigenschafts-Unterschieden zumindest maschinenlesbar – eine Verbesserung gegenüber der Anzeige von Eigenschaften in Versionen vor 1.7. Aber Subversion 1.7 bringt auch den Unterbefehl svn patch mit, das speziell darauf zugeschnitten wurde, um die zusätzlichen Informationen zu verarbeiten, die die Ausgabe von svn diff beinhalten kann, und wendet diese Änderungen auf die Arbeitskopie an. Von besonderer Bedeutung für unser Thema ist, dass in von svn diff erzeugten Patch-Dateien enthaltene Eigenschafts-Unterschiede in Subversion 1.7 und später automatisch von svn patch auf eine Arbeitskopie angewendet werden können. Mehr zu svn patch finden Sie unter svn patch in svn Referenz – Subversion-Kommandozeilen-Client.

Anmerkung

Es gibt eine Ausnahme, wie Eigenschafts-Änderungen durch svn diff angezeigt werden: Änderungen an Subversions spezieller Eigenschaft svn:mergeinfo – verwendet, um Informationen über in Ihnem Projektarchiv durchgeführte Zusammenführungen (Mergeinfo[15]) aufzuzeichnen – werden auf eine mehr menschenlesbare Art ausgegeben. Das ist ziemlich hilfreich für die Menschen, die diese Beschreibungen lesen müssen. Es hilft jedoch auch dabei, Patch-Programme (einschließlich svn patch) dazu zu bringen, diese Änderungs-Beschreibungen als Rauschen zu überspringen. Das hört sich an wie ein Fehler, es ist aber keiner, da diese Eigenschaft ausschließlich durch den Unterbefehl svn merge verwaltet werden soll. Mehr zur Verfolgung von Zusammenführungen unter Kapitel 4, Verzweigen und Zusammenführen.

Subversion 1.8 führt das Konzept ererbter Eigenschaften ein. Es gibt nichts wirklich besonderes an einer vererbbaren Eigenschaft. Tatsächlich sind alle versionierten Eigenschaften vererbbar! Der Hauptunterschied zwischen versionierten Eigenschaften vor und nach 1.8 besteht darin, das letztere einen Mechanismus zur Verfügung stellt, der es ermöglicht, die Eigenschaften der Eltern eines Zielpfades zu finden, selbst dann, wenn die Eltern nicht in der Arbeitskopie auftauchen.

Generische Vererbung von Eigenschaften offenbart sich in einigen wenigen Befehlen. Zunächst können die Unterbefehle svn proplist und svn propget alle Eigenschaften eines URL oder der Eltern eines Arbeitskopie-Pfades mit der Option --show-inherited-props abrufen. Wenn Sie möchten, können Sie das als das Gegenteil einer Unterbefehls-Operation mit --recursive betrachten: statt rekursiv in die Unterverzeichnisse eines Zieels "hinab" zu steigen, schauen Unterbefehle mit der Option --show-inherited-props "hinauf" in die Elternverzeichnisse des Ziels. Auch die Unterbefehle svnlook propget und svnlook proplist verwenden die Option --show-inherited-props auf ähnliche Weise.

Sehen wir uns einmal anhand eines Beispiels an, wie das funktioniert. Das folgende rekursive propget auf der Wurzel unserer Arbeitskopie findet heraus, dass die Eigenschaft svn:auto-props sowohl auf dem Ziel des Unterbefehls als auch auf einem seiner Unterverzeichnisse site gesetzt ist:

$ svn pg svn:auto-props --verbose -R .
Eigenschaften von ».«:
  svn:auto-props
    *.py = svn:eol-style=native
    *.c = svn:eol-style=native
    *.h = svn:eol-style=native

Eigenschaften von »site«:
  svn:auto-props
    *.html = svn:eol-style=native

Wenn wir stattdessen das Unterverzeichnis site zum Ziel des Unterbefehls machen und dabei die Option --show-inherited-props verwenden, sehen wir, dass die Eigenschaft svn:auto-props auf dem Ziel und seinem Elternverzeichnis gesetzt ist. Die Eigenschaften des Elternverzeichnisses werden als "geerbt" gekennzeichnet:

$ svn pg svn:auto-props --verbose --show-inherited-props site
Geerbte Eigenschaften von »site«,
geerbt von ».«:
  svn:auto-props
    *.py = svn:eol-style=native
    *.c = svn:eol-style=native
    *.h = svn:eol-style=native

Eigenschaften von »site«:
  svn:auto-props
    *.html = svn:eol-style=native

In den vorangegangenen Beispielen entsprach die Wurzel der Arbeitskopie der Wurzel des Projektarchivs, Eigenschaften können jedoch auch von außerhalb ererbt werden, wenn dem nicht so ist. Lassen Sie uns das Verzeichnis site aus dem vorangegangenen Beispiel auschecken und es zur Wurzel unserer Arbeitskopie machen:

$ svn co http://svn.example.com/repos site-wc
A    site-wc/publish
A    site-wc/publish/ch2.html
A    site-wc/publish/news.html
A    site-wc/publish/ch3.html
A    site-wc/publish/faq.html
A    site-wc/publish/index.html
A    site-wc/publish/ch1.html
 U   site-wc
Ausgecheckt, Revision 19.

$ cd site-wc

Wenn wir nun nach ererbten Eigenschaften auf einem Pfad der Arbeitskopie suchen, erkennen wir, dass eine Eigenschaft von einem Elternverzeichnis der Arbeitskopie ererbt ist und eine andere aus einem Elternverzeichnis des Projektarchivs das einem Ort "oberhalb" des Wurzelverzeichnisses der Arbeitskopie repräsentiert:

$ svn pg svn:auto-props --verbose --show-inherited-props publish
Geerbte Eigenschaften von »publish«,
geerbt von »http://svn.example.com/repos«:
  svn:auto-props
    *.py = svn:eol-style=native
    *.c = svn:eol-style=native
    *.h = svn:eol-style=native

Inherited properties on 'publish',
Geerbte Eigenschaften von »publish«,
geerbt von ».«:
  svn:auto-props
    *.html = svn:eol-style=native

	Warnung
	Sie können Eigenschaften nur aus Projektarchiv-Pfaden ererben, für die Sie auch eine Leseberechtigung haben – siehe „Integrierte Authentifikation und Autorisierung“ und „Autorisierungs-Optionen“. Falls Sie für einen Elternpfad keine Leseberechtigung haben, sieht es aus, als habe das Elternverzeichnis keine gesetzten Eigenschaften.

Wie oben erwähnt, unterstützen auch die Befehle svnlook proplist und svnlook propget die Option --show-inherited-props, allerdings werden die ererbten Eigenschaften nach Projektarchiv-Pfaden angezeigt statt nach Arbeitskopie-Pfaden:

$ svnlook pg repos svn:auto-props /site/publish --show-inherited-props -v
Geerbte Eigenschaften von »/site/publish«,
geerbt von »/«:
  svn:auto-props
    *.py = svn:eol-style=native
    *.c = svn:eol-style=native
    *.h = svn:eol-style=native

Geerbte Eigenschaften von »/site/publish«,
geerbt von »/site«:
  svn:auto-props
    *.html = svn:eol-style=native

Die von oberhalb der Arbeitskopie-Wurzel ererbten Eigenschaften werden in der Verwaltungsdatenbank der Arbeitskopie zwischengespeichert, wenn die Arbeitskopie erstmalig ausgecheckt wird und bei jeder Aktualisierung der Arbeitskopie aufgefrischt. Das bedeutet, dass Sie zum Ansehen ererbter Eigenschaften keinen Zugriff auf das Projektarchiv benötigen. Das erlaubt es Unterbefehlen von Subversion, die traditionell nie Zugriff auf das Projektarchiv benötigten (z.B. svn add), "abgehängt" zu bleiben, wobei stets der Zugriff auf Eigenschaften bestehen bleibt, die aus Pfaden ererbt wurden, die nicht in der Arbeitskopie vorhanden sind. Allerdings bedeutet das auch, dass ererbte Eigenschaften von oberhalb der Arbeitskopie-Wurzel sich seit Ihrer letzten Aktualisierung geändert haben könnten, so dass Ihr lokaler Zwischenspeicher nicht mehr aktuell ist. Wenn Sie also den absolut neuesten Wert einer ererbten Eigenschaft benötigen, ist es immer am sichersten, zunächst die Arbeitskopie zu aktualisieren oder direkt beim Projektarchiv nachzufragen.

An dieser Stelle mögen Sie denken, "tolle Sache, aber wozu soll das gut sein?" Allein gesehen ist die Vererbung von Eigenschaften nicht sehr nützlich. Vor 1.8 galten die reservierten Subversion-eigenen svn:*-Eigenschaften (und wahrscheinlich alle Ihrer eigenen maßgeschneiderten Eigenschaften) nur für den Pfad auf den sie definiert waren oder höchstens auf dessen unmittelbare Kindverzeichnisse.^[16] Vielmehr jedoch sind vererbbare Eigenschaften ein Werkzeug, das Subversion verwendet, um interessantere Dinge zu tun, wie automatische Eigenschaften mit der Eigenschaft svn:auto-props zu setzen oder mit der Eigenschaft svn:global-ignores Dinge zu definieren, die im gesamten Projektarchiv ignoriert werden sollen – siehe „Automatisches Setzen von Eigenschaften“ und „Ignorieren unversionierter Objekte“ zu weiteren Informationen über diese besonderen Eigenschaften und wie sie angewendet werden.

Tipp

Gegenwärtig sind vererbbare Eigenschaften in erster Linie nur nützlich hinsichtlich der Eigenschaften svn:auto-props und svn:global-ignores, doch bedeutet das nicht das Ende vom Lied. Sehen Sie in künftigen Veröffentlichungen von Subversion nach weiteren Funktionalitäten, die mit vererbbaren Eigenschaften konstruiert werden – denkbar wäre etwa ein Schablonen-Mechanismus für Protokollnachrichten. Verwenden Sie diese Funktionalität bis dahin wie Sie möchten. Irgendwelche versionierten Metadaten, die Sie auf Ihr gesamtes Projektarchiv (oder große Abschnitte daraus) anwenden möchten, können einfach in einer Eigenschaft im Wurzelverzeichnis Ihres Projektarchivs (oder des entsprechenden Teilbaums) abgelegt werden. Wir vermuten, dass einige Anwender und Administratoren pfiffige Einfälle zum Anwenden vererbbarer Eigenschaften haben werden, an die wir nie gedacht hatten.

Eigenschaften sind eine mächtige Funktionalität von Subversion, die als Schlüsselkomponenten zahlreicher Subversion-Funktionen agieren, welche an anderer Stelle in diesem und anderen Kapiteln erörtert werden – Unterstützung textueller Diffs und Zusammenführungen, Ersetzung von Schlüsselworten, Umwandlung von Zeilenenden, usw. Um jedoch den größten Nutzen aus Eigenschaften ziehen zu können, müssen sie auf den richtigen Dateien und Verzeichnissen gesetzt sein. Leider kann dieser Schritt leicht in der täglichen Routine vergessen werden, besonders deshalb, da das Versäumen des Setzens einer Eigenschaft normalerweise nicht einen offensichtlichen Fehler zur Folge hat (zumindest im Vergleich zu einer Datei, bei der versäumt wurde, sie unter Versionskontrolle zu stellen). Um Ihnen dabei zu helfen, die Eigenschaften an die Stellen zu bringen, wo sie nötig sind, bietet Subversion Ihnen ein paar einfache aber nützliche Funktionen.

Immer wenn Sie eine Datei mit svn add oder svn import unter Versionskontrolle nehmen, versucht Subversion, Sie zu unterstützen, indem es einige übliche Datei-Eigenschaften automatisch setzt. Erstens setzt Subversion auf Betriebssystemen, deren Dateisystem ein Ausführbarkeits-Erlaubnis-Bit unterstützt, automatisch die Eigenschaft svn:executable auf neu hinzugefügte oder importierte Dateien, bei denen das Ausführbarkeits-Bit gesetzt ist. (Siehe „Ausführbarkeit von Dateien“ weiter unten in diesem Kapitel für weitere Informationen zu dieser Eigenschaft.)

Zweitens versucht Subversion, den MIME-Typen der Datei zu ermitteln. Falls Sie einen Laufzeitparameter mime-types-files konfiguriert haben, versucht Subversion in dieser Datei einen passenden MIME-Typen für die Endung Ihrer Datei zu finden. Wenn es fündig wird, setzt es die Eigenschaft svn:mime-type Ihrer Datei auf den gefundenen MIME-Typen. Falls keine Datei konfiguriert oder kein passender Typ für die Dateiendung gefunden wurde, verwendet Subversion stattdessen heuristische Algorithmen, um den MIME-Typen der Datei zu ermitteln. Abhängig davon, wie es gebaut wurde, kann Subversion 1.7 Dateiprüfungs-Bibliotheken verwenden^[17], um den Dateitypen aufgrund des Inhalts zu bestimmen. Falls all das fehlschlägt, benutzt Subversion seine eigene recht einfache Heuristik, um festzustellen, ob die Datei nicht-textuellen Inhalt hat. Falls das der Fall ist, wird automatisch die Eigenschaft svn:mime-type dieser Datei auf application/octet-stream gesetzt (der allgemeine „dies ist eine Ansammlung von Bytes“-MIME-Type). Falls Subversion falsch rät, oder falls Sie den Wert der Eigenschaft svn:mime-type präziser setzen möchten – etwa image/png oder application/x-shockwave-flash – können Sie natürlich jederzeit die Eigenschaft entfernen oder bearbeiten. (Mehr zur Verwendung von MIME-Typen durch Subversion in „Datei-Inhalts-Typ“ später in diesem Kapitel.)

Anmerkung

UTF-16 wird häufig verwendet, um Dateien zu kodieren, deren semantischer Inhalt zwar textueller Natur ist, die allerdings voller Bytes außerhalb des typischen ASCII-Zeichenraums sind. Als solche neigt Subversion dazu, diese Dateien als binär zu klassifizieren, sehr zum Leidwesen von Anwendern, die zeilenweise Unterschiedungen und Zusammenführungen, Schlüsselwortersetzungen und andere Verhaltensweisen für diese Dateien wünschen.

Darüber hinaus bietet Subversion über sein Laufzeit-Konfigurationssystem (siehe „Laufzeit-Konfigurations-Bereich“) eine flexible Möglichkeit, automatisch Eigenschaften zu setzen, die es Ihnen erlaubt, Abbildungen von Dateinamensmustern auf Eigenschafts-Namen und -Werte vorzunehmen. Auch hier haben diese Abbildungen Auswirkungen auf das Hinzufügen und Importieren und können nicht nur die standardmäßigen Entscheidungen Subversions bezüglich des Mime-Typs außer Kraft setzen, sondern auch zusätzliche Subversion- oder spezielle Eigenschaften setzen. Beispielsweise könnten Sie eine Abbildung definieren, die bestimmt, dass jedes Mal wenn eine JPEG-Datei hinzugefügt wird – Dateien, deren Namen auf das Muster *.jpg passen – Subversion automatisch die Eigenschaft svn:mime-type für diese Dateien auf image/jpeg setzt. Oder vielleicht sollen alle Dateien mit dem Muster *.cpp svn:eol-style auf native und svn:keywords auf Id gesetzt bekommen. Für weitere Details zur Unterstützung automatischer Eigenschaften in der Laufzeit-Konfiguration siehe „Allgemeine Konfiguration“

Obwohl die Unterstützung automatischer Eigenschaften über das Laufzeit-Konfigurations-System gewiss sehr praktisch ist, bevorzugen Subversion-Administratoren vielleicht eine Menge von Eigenschafts-Definitionen, die von allen Clients automatisch berücksichtigt werden, wenn sie aur Arbeitskopien arbeiten, die von einem bestimmten Server ausgecheckt worden sind. Subversion 1.8 und neuere Clients unterstützen diese Funktionalität mithilfe der vererbbaren Eigenschaft svn:auto-props.

Die Eigenschaft svn:auto-props funktioniert wie die Laufzeit-Konfiguration, die das automatische Setzen von Eigenschaften beim Hinzufügen oder Importieren ermöglicht. Es wird erwartet, dass der Wert der Eigenschaft svn:auto-props dem Wert der Laufzeit-Konfigurations-Option auto-props entspricht (d.h., alle Schlüssel-Wert-Paare im Format FILE_PATTERN = PROPNAME=VALUE[;PROPNAME=VALUE ...]). Wie bei der Laufzeit-Option auto-props kann auch die Eigenschaft svn:auto-props außer Acht gelassen werdem, wenn die Option --no-auto-props verwendet wird, jedoch wird, anders als bei der Konfigurations-Option, die Eigenschaft svn:auto-props nicht außer Kraft gesetzt, wenn die Konfigurations-Option enable-auto-props auf no gesetzt wird.

Nehmen wir beispielsweise an, Sie hätten eine Arbeitskopie von Ihrem trunk-Zweig ausgecheckt und müssen eine neue Datei hinzufügen (dabei nehmen wir weiter an, dass automatische Eigenschaften in Ihren Laufzeit-Konfiguration abgestellt sind):

$ svn st
?       calc/data.c

$ svn add calc/data.c
A         calc/data.c

$ svn proplist -v calc/data.c
Eigenschaften von »calc/data.c«:
  svn:eol-style
    native

Beachten Sie, dass die Eigenschaft svn:eol-style automatisch auf die Datei data.c gesetzt wurde, nachdem sie die unversionierte Datei unter Versionskontrolle gestellt hatten. Da wir annahmen, dass die Laufzeit-Option auto-props abgestellt war, wissen wir, dass die Eigenschaft svn:auto-props auf irgendeinem Elternpfad von data.c gesetzt sein muss. Durch die Verwendung des Unterbefehls svn propget mit der Option --show-inherited-props sehen wir, dass es sich tatsächlich so verhält:

$ svn propget svn:auto-props --show-inherited-props -v calc
Geerbte Eigenschaften von »calc«,
geerbt von »http://svn.example.com/repos«:
  svn:auto-props
    *.py = svn:eol-style=native
    *.c = svn:eol-style=native
    *.h = svn:eol-style=native

Anders als die Eigenschaft svn:global-ignores und ihre analoge Laufzeit-Konfiguration global-ignores, die kombiniert werden, überschreibt die Eigenschaft svn:auto-props die Laufzeit-Konfiguration auto-props, falls sie eine automatische Eigenschaft für das gleiche Muster wie die Laufzeit-Konfiguration definiert. Automatische Eigenschaften, die von einem Pfad ererbt wurden^[18] können ebenfalls das identische Muster überschreiben, welches von einem anderen Pfad ererbt wurde. Diese Hierarchie für Überschreibungen funktioniert wie folgt:

Lassen Sie uns einmal ein Beispiel ansehen. Angenommen, Sie haben diese Laufzeit-Konfiguration:

[miscellany]
enable-auto-props = yes
[auto-props]
*.py  = svn:eol-style=CR
*.c   = svn:eol-style=CR
*.h   = svn:eol-style=CR
*.cpp = svn:eol-style=CR

Nun möchten Sie drei Dateien dem Verzeichnis calc Ihrer Arbeitskopie hinzufügen:

$ svn st
?       calc/data-binding.cpp
?       calc/data.c
?       calc/editor.py

Lassen Sie uns überprüfen, welche svn:auto-props für calc zutreffen:

$ svn propget svn:auto-props -v --show-inherited-props calc
Geerbte Eigenschaften von »calc«,
geerbt von »http://svn.example.com/repos«:
  svn:auto-props
    *.py = svn:eol-style=native
    *.c = svn:eol-style=native
    *.h = svn:eol-style=native

Geerbte Eigenschaften von »calc«,
geerbt von ».«:
  svn:auto-props
    *.py = svn:eol-style=native
    *.c = svn:keywords=Author Date Id Rev URL

Welche automatischen Eigenschaften erwarten wir, wenn wir diese drei Dateien hinzufügen? Wir fügen das Trio hinzu und sehen dann nach:

$ svn add calc --force
A         calc/data-binding.cpp
A         calc/data.c
A         calc/editor.py

Die Datei data-binding.cpp hat nur ein passendes Muster, *.cpp = svn:eol-style=CR in der Laufzeit-Konfiguration, also wird offensichtlich die Eigenschaft svn:eol-style auf CR gesetzt:

$ svn proplist -v calc/data-binding.cpp
Eigenschaften von »calc/data-binding.cpp«:
  svn:eol-style
    CR

Die Datei editor.py passt auf ein einzelnes Muster in der Laufzeit-Konfiguration und auf beide der svn:auto-props Eigenschaften, jedoch hat die explizit auf calc gesetzte Eigenschaft *.py = svn:eol-style=native gemäß der beschriebenen Hierarchie Vorrang. Also wird die Eigenschaft svn:eol-style auf native: gesetzt:

$ svn proplist -v calc/editor.py
Eigenschaften von »calc/editor.py«:
  svn:eol-style
    native

Die Datei data.c passt auf Muster in der Laufzeit-Konfiguration und auf beide der ererbten svn:auto-props Eigenschaften. Die automatische Eigenschaft svn:keywords ist nur einmal definiert, auf calc, also bekommt data.c diese Eigenschaft automatisch. Die svn:auto-props auf calc definieren jedoch keinen Wert für svn:eol-style, also stellt der nächste vererbende Elternteil, http://svn.example.com/repos, diesen Wert zur Verfügung:

$ svn proplist -v calc/data.c
Eigenschaften von »calc/data.c«:
  svn:eol-style
    native
  svn:keywords
    Author Date Id Rev URL

Warnung

Das Überschreiben automatischer Eigenschaften trifft nur auf identische Muster zu. Falls eine hinzuzufügende oder zu importierende Datei auf mehr als ein Muster passt, gibt es keine Garantie, welche zu einem Muster passende automatische Eigenschaft angewendet wird. Nehmen wir beispielsweise an, dass Sie die Datei foo.cpp dem Verzeichnis bar hinzufügen möchten. Nehmen wir weiter an, dass die Eigenschaft svn:auto-props auf bar mit dem folgenden Wert gesetzt ist: *.c* = svn:eol-style=native *.cpp = svn:eol-style=native;svn:keywords=Author Date Id Rev URL Da foo.cpp auf beide Muster passt, gibt es keine Möglichkeit, herauszufinden, ob die Eigenschaft svn:keywords beim Hinzufügen von foo.cpp gesetzt wird.

Eine abschließende Bemerkung zu svn:auto-props. Diese Eigenschaft (gemeinsam mit dem ähnlichen svn:global-ignores, siehe „Ignorieren unversionierter Objekte“) stellt lediglich eine Empfehlung für Clients dar, die die Bedeutung der Eigenschaft verstehen. Ältere Clients werden diese Eigenschaften ignorieren, die Option --no-auto-props wird sie außer Acht lassen, ein Anwender kann einfach manuell automatische Eigenschaften ändern oder entfernen, nachdem sie gesetzt wurden – es gibt viele Möglichkeiten, die empfohlenen Eigenschaften aus svn:auto-props zu umgehen. Unter diesen Voraussetzungen müssen Administratoren immer noch Hook-Skripte verwenden, um sicherzustellen, dass die Eigenschaften, die Dateien hinzugefügt wurden oder dort verändert wurden, den bevorzugten Richtlinien der Administratoren entsprechen, wobei Übertragungen zurückgewiesen werden, die dem nicht entsprechen. (Siehe „Erstellen von Projektarchiv-Hooks“ für mehr zu Hook-Skripten.)

In diesem Abschnitt fassen wir kurz all diejenigen Eigenschaften zusammen, die Subversion für die eigene Verwendung reserviert. Wir werden uns beide Arten von Eigenschaften ansehen – diejenigen, die mit individuellen, versionierten Dateien und Verzeichnissen verbunden sind und solchen, die zu Revisionen gehören.