Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.
Glücklicherweise verhält sich das Kommandozeilenprogramm von Subversion für routinemäßig auf verschiedenen Rechnern mit unterschiedlichen Betriebssystemen arbeitende Benutzer unter all diesen Betriebssystemen fast identisch. Wenn Sie wissen, wie svn auf der einen Plattform eingesetzt wird, wissen Sie auch, wie es woanders geht.
Jedoch trifft das nicht immer auf andere allgemeine Klassen von Software zu oder die eigentlichen Dateien, die Sie mit Subversion verwalten. Beispielsweise ist die Definition einer „Textdatei“ auf einer Windows-Maschine ähnlich der auf einer Linux-Kiste, jedoch mit einem wichtigen Unterschied: die Zeichenfolge zum Markieren der Zeilenenden dieser Dateien. Es gibt auch andere Unterschiede. Unix-Plattformen haben symbolische Links (die Subversion unterstützt), während es sie unter Windows nicht gibt. Unix-Plattformen verwenden Dateisystem-Berechtigungen, um die Ausführbarkeit zu ermitteln, während Windows Dateiendungen benutzt.
Da Subversion nicht in der Position ist, die gesamte Welt durch gemeinsame Definitionen und Implementierungen all dieser Dinge zu vereinen, ist das beste, was es tun kann, Ihr Leben zu vereinfachen, falls Sie mit Ihren versionierten Dateien und Verzeichnissen auf mehreren Rechnern und Betriebssystemen arbeiten müssen. Dieser Abschnitt beschreibt einige der Methoden, die Subversion hierfür verwendet.
Subversion reiht sich unter den zahlreichen Anwendungen
ein, die die Multipurpose Internet Mail Extensions (MIME)
Inhaltstypen erkennen und verwenden. Außer ein universeller
Lagerort für den Inhaltstypen einer Datei zu sein, bestimmt
der Wert der Datei-Eigenschaft
svn:mime-type
einige Verhaltensweisen von
Subversion selbst.
Beispielsweise ist einer der Vorteile, die Subversion
typischerweise mitbringt, die kontextabhängige, zeilenbasierte
Zusammenführung der vom Server während einer Aktualisierung
empfangenen Änderungen mit Ihrer Arbeitsdatei. Allerdings gibt
es bei Dateien, deren Inhalt nicht aus Text besteht, oft nicht
das Konzept einer „Zeile“. Damit versucht
Subversion während einer Aktualisierung keine
kontextabhängigen Zusammenführungen für versionierte Dateien,
deren Eigenschaft svn:mime-type
auf einen
nicht-textuellen MIME-Typen gesetzt ist (normalerweise etwas,
das nicht mit text/
beginnt, obwohl es
Ausnahmen gibt). Stattdessen wird jedes Mal, wenn eine von
Ihnen lokal veränderte binäre Datei in der Arbeitskopie
aktualisiert werden soll, diese nicht angerührt, sondern
Subversion erzeugt zwei neue Dateien. Eine davon hat die
Dateiendung .oldrev
und beinhaltet die
BASE-Revision der Datei. Die andere Datei hat eine
.newrev
-Endung und beinhaltet die
aktualisierte Revision der Datei. Dieses Verhalten dient
tatsächlich dem Schutz des Benutzers vor fehlgeschlagenen
Versuchen, kontextabhängige Zusammenführungen mit Dateien zu
machen, die einfach nicht kontextabhängig zusammengeführt
werden können.
Darüber hinaus rufen Dateien nicht-textuellen MIME-Typs
Fehler hervor, wenn Sie als Ziele von Operationen wie
svn diff und svn
annotate verwendet werden, da zeilenbasierte
Unterschiede und Anmerkungen offensichtlich an eine sinnvolle
Definition von „Zeile“ für eine gegebene Datei
geknüpft sind. Das kann besonders frustrierend für Anwender
von XML-Dateien sein, deren Eigenschaft
svn:mime-type
einen Wert wie etwa
application/xml
besitzt, der nicht
eindeutig menschenlesbar ist und somit von Subversion als
nicht-textuell behandelt wird. Glücklicherweise bieten diese
Unterbefehle eine Option --force
an, die
Subversion zwingen, diese Operationen trotz der anscheinenden
Nicht-Menschenlesbarkeit der Dateien zu versuchen.
Warnung | |
---|---|
Falls die Eigenschaft |
Subversion stellt eine Anzahl von Mechanismen zur
Verfügung, mit denen automatisch die Eigenschaft
svn:mime-type
an einer versionierten Datei
gesetzt werden kann. Siehe „Automatisches Setzen von Eigenschaften“ für Details.
Falls die Eigenschaft svn:mime-type
gesetzt ist, verwendet auch das Subversion-Apache-Modul dessen
Wert, um den HTTP-Header Content-type:
zu
füllen, wenn es auf GET-Anfragen antwortet. Das gibt Ihrem
Web-Browser einen wichtigen Hinweis darauf, wie die Datei
darzustellen ist, wenn Sie sie benutzen, um den Inhalt Ihres
Subversion-Projektarchivs zu durchstöbern.
Unter vielen Betriebssystemen hängt die Fähigkeit, eine
Datei als Befehl ausführen zu können, vom Vorhandensein eines
Ausführbarkeits-Erlaubnis-Bits ab. Normalerweise ist dieses
Bit standardmäßig nicht aktiviert und muss vom Benutzer für
jede Datei gesetzt werden, die es benötigt. Es wäre aber ein
Riesenstress, sich exakt diejenigen Dateien in einer frisch
ausgecheckten Arbeitskopie merken zu müssen, die das
Ausführbarkeits-Bit gesetzt haben sollen und es dann zu
aktivieren. Deshalb stellt Subversion die Eigenschaft
svn:executable
zur Verfügung, um die
Dateien zu markieren, die das Ausführbarkeits-Bit benötigen.
Beim Auschecken berücksichtigt Subversion diesen Wunsch wenn
es die Arbeitskopie mit solchen Dateien füllt.
Diese Eigenschaft hat keine Auswirkungen auf
Dateisystemen, die das Konzept eines Ausführbarkeits-Bits
nicht kennen, so wie FAT32 und NTFS[21]. Darüber hinaus erzwingt
Subversion beim Setzen dieser Eigenschaft den Wert
*
, obwohl sie keine definierten Werte
besitzt. Zum Schluss sei gesagt, dass diese Eigenschaft nur
auf Dateien gültig ist, nicht auf Verzeichnissen.
Falls der Inhalt einer versionierten Datei durch deren
Eigenschaft svn:mime-type
nicht anders
gekennzeichnet ist, nimmt Subversion an, es handele sich
um menschenlesbare Daten. Im Allgemeinen verwendet Subversion
dieses Wissen lediglich, um festzustellen, ob Unterschiede
kontextabhängig dargestellt werden können. Ansonsten sind
für Subversion Bytes einfach Bytes.
Das bedeutet, dass Subversion von sich aus überhaupt
nicht auf die von Ihren Dateien benutzte Sorte von
Zeilenende-Markierungen (EOL-Marker)
achtet. Leider haben unterschiedliche Betriebssysteme auch
unterschiedliche Konventionen hinsichtlich der Zeichenfolgen,
die das Ende einer Textzeile in einer Datei repräsentieren.
Beispielsweise ist die gebräuchliche Zeilenende-Kennzeichnung,
die von Software auf der Windows-Plattform benutzt wird, ein
Paar aus ASCII-Kontrollzeichen – ein Wagenrücklauf
(CR
) gefolgt von einem Zeilenvorschub
(LF
). Unix Software verwendet jedoch nur
das Zeichen LF
, um Zeilenenden
zu kennzeichnen.
Nicht alle der zahlreichen Werkzeuge unter diesen
Betriebssystemen können mit Dateien umgehen, die Zeilenenden
in einem Format haben, das vom spezifischen
Zeilenende-Stil des Betriebssystems abweicht, auf
dem sie laufen. Unix-Programme behandeln das in
Windows-Dateien vorkommende Zeichen CR
typischerweise als ein gewöhnliches Zeichen (welches
normalerweise als ^M
wiedergegeben wird),
und Windows-Programme fügen alle Zeilen einer Unix-Datei zu
einer großen Zeile zusammen, da keine
CR
-Zeichen zur Zeilenendemarkierung
gefunden wurden.
Diese Empfindlichkeit gegenüber fremden EOL-Markern kann für Menschen frustrierend sein, die eine Datei über Betriebssystemgrenzen hinweg gemeinsam benutzen. Schauen wir uns beispielsweise eine Quelltextdatei an, die Entwickler sowohl unter Windows als auch unter Unix bearbeiten. Falls die Entwickler stets Werkzeuge verwenden, die den Zeilenende-Stil der Datei bewahren, werden keine Probleme auftreten.
In der Praxis jedoch scheitern viele verbreitete Werkzeuge daran, eine Datei mit fremden EOL-Markern richtig zu lesen, oder sie wandeln die Zeilenenden der Datei beim Schreiben in den eigenen Stil. Falls ersteres für einen Entwickler zutrifft, muss ein externes Umwandlungsprogramm verwendet werden (etwa dos2unix oder sein Gegenstück unix2dos), um die Datei für die Bearbeitung vorzubereiten. Im letzteren Fall ist keine spezielle Vorbereitung notwendig. In beiden Fällen jedoch ist das Ergebnis eine Datei, die sich buchstäblich in jeder Zeile vom Original unterscheidet. Vor der Übertragung seiner Änderungen hat der Benutzer zwei Möglichkeiten: Entweder kann er mit einem Umwandlungsprogramm den Zeilenende-Stil wiederherstellen, den die Datei vor den Änderungen aufwies, oder er überträgt die Datei einfach – neue EOL-Marker und alles andere inklusive.
Unter dem Strich bedeuten derartige Szenarien Zeitverschwendung und unnötige Änderungen an übertragenen Dateien. Zeitverschwendung ist schlimm genug. Falls jedoch durch die Übertragungen alle Zeilen einer Datei geändert werden, erschwert das die Aufgabe, herauszufinden, welche Zeilen sich auf eine nicht-triviale Art und Weise geändert haben. Wo wurde der Fehler tatsächlich behoben? In welcher Zeile hat sich ein Syntaxfehler eingeschlichen?
Die Lösung für dieses Problem ist die Eigenschaft
svn:eol-style
. Wird sie auf einen gültigen
Wert gesetzt, benutzt Subversion sie, um festzustellen, welche
besondere Behandlung für diese Datei notwendig ist, um das
ständige durch unterschiedliche Betriebssysteme bedingte Hin
und Her der Zeilenende-Stile bei jeder Übertragung zu
vermeiden. Die gültigen Werte sind:
native
Das führt dazu, dass die Datei die EOL-Marker
enthält, die in dem Betriebssystem üblich sind,
unter dem Subversion läuft. Mit anderen Worten: Falls ein
Benutzer auf einem Windows-Rechner eine Arbeitskopie
auscheckt, zu der eine Datei mit einer auf
native
gesetzten Eigenschaft
svn:eol-style
gehört, wird die Datei
CRLF
-EOL-Marker beinhalten. Ein
Unix-Benutzer, der eine Arbeitskopie mit derselben Datei
auscheckt, wird in seiner Kopie der Datei
LF
-EOL-Marker sehen.
Beachten Sie, dass Subversion die Datei, unabhängig
vom Betriebssystem, tatsächlich unter Verwendung
normalisierter LF
-EOL-Marker im
Projektarchiv ablegt. Das geschieht jedoch grundsätzlich
transparent für den Benutzer.
CRLF
Das führt dazu, dass die Datei unabhängig vom
Betriebssystem die Zeichenfolge CRLF
als EOL-Marker enthält.
LF
Das führt dazu, dass die Datei unabhängig vom
Betriebssystem das Zeichen LF
als
EOL-Marker enthält.
CR
Das führt dazu, dass die Datei unabhängig vom
Betriebssystem das Zeichen CR
als
EOL-Marker enthält. Dieser Zeilenende-Stil ist nicht
sehr verbreitet