Größtenteils wegen der Einfachheit des Gesamtentwurfs des Subversion-Repositorys und der ihm zugrundeliegenden Technik, ist die Erstellung und Konfiguration eines Repositorys eine ziemlich unkomplizierte Aufgabe. Es gibt einige Entscheidungen, die Sie im Vorfeld treffen sollten, jedoch sind die eigentlichen Arbeitsschritte für die Einrichtung eines Subversion-Repositorys recht einfach und neigen zur stupiden Fleißarbeit, falls Sie mehrere davon aufzusetzen haben.
Einige Dinge, die Sie jedoch im Vorfeld sorgfältig prüfen sollten, sind:
-
Welche Art von Daten sollen in Ihrem Repository (oder Repositorys) abgelegt werden, und wie sind diese Daten organisiert?
-
Wo soll Ihr Repository untergebracht werden, und wie soll darauf zugegriffen werden?
-
Welche Art von Zugriffskontrolle und Ereignisbenachrichtigung benötigen Sie?
-
Welche der verfügbaren Datenspeicherungsarten möchten Sie verwenden?
In diesem Abschnitt werden wir versuchen, Ihnen beim Beantworten dieser Fragen zu helfen.
Obwohl Subversion Ihnen erlaubt, versionierte Dateien und Ordner ohne Informationsverlust hin und her zu verschieben und sogar Methoden anbietet, um versionierte Geschichte von einem Repository in ein anderes zu verschieben, kann das ziemlich den Arbeitsablauf derjenigen stören, die oft auf das Repository zugreifen und gewisse Dinge an bestimmten Orten erwarten. Bevor Sie ein neues Repository erstellen, sollten Sie also versuchen, ein wenig in die Zukunft zu schauen; planen Sie weitsichtig, bevor Sie Ihre Daten unter Versionskontrolle stellen. Durch die vorzeitige gewissenhafte „Anlage“ Ihres Repositorys oder mehrerer Repositorys können Sie viel künftigen Kopfschmerz vermeiden.
Nehmen wir an, Sie seien als Repository-Administrator für die Versionskontrollsysteme mehrerer Projekte zuständig. Ihre erste Entscheidung ist, ob Sie ein einzelnes Repository für mehrere Projekte verwenden, jedem Projekt sein eigenes Repository geben oder einen Kompromiss aus diesen beiden Lösungen haben wollen.
Ein einzelnes Repository für mehrere Projekte zu verwenden, hat einige Vorteile, am offensichtlichsten ist der vermiedene doppelte Verwaltungsaufwand. Ein einzelnes Repository bedeutet, dass es nur einen Satz Hook-Programme, ein Ding zum routinemäßigen Sichern, ein Ding für einen Auszug und zum anschließenden Laden nach einer inkompatiblen neuen Version von Subversion gibt usw. Sie können Daten auch einfach zwischen Projekten verschieben, ohne historische Versionierungsinformationen zu verlieren.
Der Nachteil bei der Verwendung eines einzelnen Repositorys ist, dass unterschiedliche Projekte auch unterschiedliche Anforderungen hinsichtlich der Repository-Ereignis-Trigger haben, wie etwa Benachrichtigungs-E-Mails bei Commits an unterschiedliche Verteiler, oder unterschiedliche Definitionen dazu, was eine berechtigte Übergabe ist und was nicht. Das sind natürlich keine unüberwindbaren Probleme – es bedeutet nur, dass all Ihre Hook-Skripte die Struktur Ihres Repositorys beachten müssen, anstatt davon auszugehen, dass das gesamte Repository von einer einzelnen Gruppe zugeordnet ist. Beachten Sie auch, dass Subversion Versionsnummern verwendet, die global für das gesamte Repository gelten. Obwohl diese Nummern keine Zauberkräfte haben, mögen manche Zeitgenossen es trotzdem nicht, dass, obwohl in letzter Zeit keine Änderungen in ihrem Projekt durchgeführt worden sind, die jüngste Versionsnummer im Repository ständig höher wird, weil andere Projekte fleißig neue Revisionen hinzufügen. [27]
Es kann auch eine Lösung in der Mitte gewählt werden. Beispielsweise können Projekte danach geordnet werden, wie stark sie miteinander verbunden sind. Sie könnten ein paar Repositorys haben, die jeweils eine handvoll Projekte beherbergen. Auf diese Art können Projekte, die wahrscheinlich gemeinsame Daten verwenden wollen, dies auch einfach bewerkstelligen, und wenn dem Repository neue Versionen hinzugefügt werden, wissen die Entwickler wenigstens, dass diese neuen Revisionen zumindest entfernt eine Beziehung zu jedem Benutzer dieses Repositorys haben.
Nachdem Sie entschieden haben, wie Sie Ihre Projekte in
Repositorys aufteilen, möchten Sie sich nun vielleicht
Gedanken darüber machen, welche Verzeichnishierarchien Sie im
Repository anlegen wollen. Da Subversion zum Verzweigen und
Etikettieren reguläre Verzeichniskopien verwendet (siehe Kapitel 4, Verzweigen und Zusammenführen), empfiehlt die
Subversion-Gemeinschaft, dass Sie einen Ort im Repository für
jedes Projekt-Wurzelverzeichnis wählen
– das oberste Verzeichnis, das Daten für Ihr Projekt
enthält – und hierunter dann drei Unterverzeichnisse
anlegen: trunk, das Verzeichnis, in dem
die Hauptentwicklung stattfindet,
branches, zur Aufnahme verschiedener
Zweige der Hauptentwicklungslinie und
tags, als Sammlung von Momentaufnahmen
des Verzeichnisbaums, die erzeugt, vielleicht gelöscht, jedoch
nie verändert werden.
[28]
Ihr Repository könnte z.B. so aussehen:
/
calc/
trunk/
tags/
branches/
calendar/
trunk/
tags/
branches/
spreadsheet/
trunk/
tags/
branches/
…
Beachten Sie, dass es unerheblich ist, wo in Ihrem Repository sich das Wurzelverzeichnis Ihres Projektes befindet. Falls Sie nur ein Projekt pro Repository haben, ist der logische Ort für das Wurzelverzeichnis des Projektes das Wurzelverzeichnis des zum Projekt gehörenden Repositorys. Falls Sie mehrere Projekte haben, möchten Sie diese vielleicht innerhalb des Repositorys gruppieren, indem Sie Projekte ähnlichen Zwecks in demselben Unterverzeichnis unterbringen oder sie vielleicht nur alphabetisch gruppieren. Eine solche Anordnung könnte so aussehen:
/
utils/
calc/
trunk/
tags/
branches/
calendar/
trunk/
tags/
branches/
…
office/
spreadsheet/
trunk/
tags/
branches/
…
Legen Sie Ihr Repository so an, wie es Ihnen am besten passt. Subversion erwartet oder erzwingt keine bestimmte Anordnung – für Subversion ist und bleibt ein Verzeichnis ein Verzeichnis. Letztendlich sollten Sie für ein Repository eine Struktur wählen, die den Bedürfnissen der Leute gerecht wird, die an den Projekten arbeiten, die dort untergebracht sind.
Der Vollständigkeit halber erwähnen wir noch eine weitere,
verbreitete Anordnung. Bei dieser Anordnung befinden sich die
Verzeichnisse trunk,
tags und branches im
Wurzelverzeichnis des Repositorys und die Projekte in
Unterverzeichnissen davon:
/
trunk/
calc/
calendar/
spreadsheet/
…
tags/
calc/
calendar/
spreadsheet/
…
branches/
calc/
calendar/
spreadsheet/
…
An dieser Anordnung ist zwar nichts verkehrt, allerdings könnte es für Ihre Benutzer mehr oder weniger intuitiv sein. Besonders in Situationen mit vielen Projekten und entsprechend vielen Benutzern, kann es vorkommen, dass die Benutzer gewöhnlich nur mit einem oder zwei dieser Projekte vertraut sind. Allerdings schwächt dieser Projekt-als-Geschwister-Zweig-Ansatz die Betonung auf Projekt-Individualität und betrachtet die Gesamtmenge der Projekte als Ganzes. Das ist jedoch ein sozialer Aspekt. Wir mögen unseren ursprünglich geäußerten Vorschlag aus rein praktischen Erwägungen – es ist einfacher, in der kompletten Historie eines einzelnen Projektes zu forschen (oder sie zu verändern oder woandershin zu migrieren), wenn es einen einzelnen Pfad im Repository gibt, der die gesamte Historie für dieses eine Projekt, und nur dieses, beinhaltet – die Vergangenheit, Tags und Zweige.
Bevor Sie Ihr Subversion-Repository anlegen, bleibt die offensichtliche Frage zu beantworten, wo das Ding hin soll. Das hängt eng mit etlichen weiteren Fragen zusammen, etwa wie auf das Repository zugegriffen werden soll (über einen Subversion-Server oder direkt), wer darauf zugreifen soll (Benutzer hinter Ihrer Firmen-Firewall oder die weite Welt im offenen Netz), welche zusätzlichen Dienste Sie im Zusammenhang mit Subversion anbieten wollen (Schnittstellen zum Stöbern im Repository, Übergabebenachrichtigungen per E-Mail usw.), Ihre Sicherungsstrategie und vieles mehr.
Die Auswahl und Konfigurierung des Servers werden wir in Kapitel 6, Die Administration eines Subversion-Servers behandeln; jedoch möchten wir an dieser Stelle kurz darauf hinweisen, dass die Antworten auf einige der anderen Fragen zur Folge haben, dass Sie bei der Entscheidung über den Speicherorte für das Repository keine freie Wahl mehr haben. Beispielsweise könnten bestimmte Einsatzumgebungen erfordern, dass von mehreren Rechnern über ein freigegebenes Dateisystem auf das Repository zugegriffen werden muss, so dass (wie Sie im nächsten Abschnitt lesen werden) die Wahl der dem Repository zugrundeliegenden Datenspeicherung gar keine Wahl mehr ist, da nur eine der verfügbaren Datenspeicherungsverfahren in dieser Umgebung funktionieren wird.
Es ist unmöglich, und würde auch den Rahmen dieses Buches sprengen, wenn jede erdenkliche Einsatzart von Subversion angesprochen würde. Wir ermutigen Sie einfach, Ihre Optionen zu prüfen, indem Sie diese Seiten und weitere Quellen als Referenz verwenden und weitsichtig planen.
Subversion unterstützt zwei Optionen für das zugrundeliegende Datenspeicherungsverfahren – oft bezeichnet als „das Backend“ oder, etwas verwirrend, „das (versionierte) Dateisystem“ — welches jedes Repository verwendet. Das eine Verfahren speichert alles in einer Berkeley-DB- (oder BDB-) Datenbankumgebung; Repositorys, die dieses Verfahren verwenden, werden oft „BDB-basiert“ genannt. Das andere Verfahren speichert die Daten in gewöhnlichen, flachen Dateien, die ein spezielles Format verwenden. Unter Subversion-Entwicklern hat sich dafür die Bezeichnung FSFS [29] eingebürgert – eine Implementierung eines versionierten Dateisystems, dass direkt das Dateisystem des Betriebssystems verwendet – statt einer Datenbankbibliothek oder einer anderen Abstraktionsebene – um Daten zu speichern
Tabelle 5.1, „Vergleich der Repository-Datenspeicherung“ liefert einen Vergleich zwischen Berkeley-DB- und FSFS-Repositorys.
Tabelle 5.1. Vergleich der Repository-Datenspeicherung
| Kategorie | Funktion | Berkeley DB | FSFS |
|---|---|---|---|
| Zuverlässigkeit | Unversehrtheit der Daten | Höchst zuverlässig, wenn es richtig aufgesetzt wird; Berkeley DB 4.4 bringt automatische Wiederherstellung | Ältere Versionen hatten einige selten aufgetretene, jedoch datenzerstörende Fehler |
| Empfindlichkeit gegenüber Unterbrechungen | Sehr; Abstürze und Berechtigungsprobleme können die Datenbank „verklemmt“ hinterlassen, was eine Wiederherstellung mithilfe des Journals erfordert | Ziemlich unempfindlich | |
| Zugriffsmöglichkeiten | Benutzbar über eine Laufwerk mit Nur-Lese-Zugriff | Nein | Ja |
| Plattformunabhängige Speicherung | Nein | Ja | |
| Benutzbar über Netz-Dateisysteme | Im Allgemeinen nicht | Ja | |
| Behandlung von Gruppenberechtigungen | Empfindlich für Probleme mit der Benutzer-umask; Zugriff am besten nur durch einen Benutzer | Umgeht umask-Probleme | |
| Skalierbarkeit | Plattenplatzbedarf des Repositorys | Größer (besonders, wenn Protokolldateien nicht gekürzt werden) | Kleiner |
| Anzahl an Revisionsbäumen | Datenbank; keine Probleme | Einige ältere Dateisysteme lassen sich mit tausenden Einträgen in einem Verzeichnis nicht gut skalieren | |
| Verzeichnisse mit vielen Dateien | Langsamer | Schneller | |
| Arbeitsleistung | Auschecken der letzten Revision | Kein spürbarer Unterschied | Kein spürbarer Unterschied |
| Große Übergaben | Insgesamt langsamer, aber die Kosten amortisieren sich über die Dauer der Übergabe | Insgesamt schneller, jedoch können Abschlussarbeiten zu Zeitüberschreitungen beim Client führen. |
Beide dieser Verfahren haben Vor- und Nachteile. Keins davon ist „offizieller“ als das andere, obwohl das neuere FSFS seit Subversion 1.2 das Standardverfahren ist. Beide verfügen über die ausreichende Zuverlässigkeit, um ihnen Ihre versionierten Daten anzuvertrauen. Doch wie sie in Tabelle 5.1, „Vergleich der Repository-Datenspeicherung“ sehen können, bietet das FSFS-Verfahren bezüglich seiner unterstützten Einsatzumgebungen wesentlich mehr Flexibilität. Mehr Flexibilität bedeutet, dass Sie sich mehr anstrengen müssen, um es falsch einzusetzen. Dies sind die Gründe – hinzu kommt, dass beim Verzicht auf Berkeley DB sich eine Komponente weniger im System befindet – warum heutzutage beinahe jeder das FSFS-Verfahren verwendet, wenn neue Repositorys angelegt werden.
Glücklicherweise interessiert es die meisten Programme die auf Subversion-Repositorys zugreifen nicht, welches Speicherverfahren verwendet wird. Außerdem sind Sie mit Ihrer ersten Entscheidung für das Speicherverfahren nicht notwendigerweise festgelegt – falls Sie es sich später anders überlegen sollten, bietet Subversion Methoden zur Migration der Daten im Repository in ein anderes Repository, das ein unterschiedliches Speicherverfahren verwendet. Wir werden das später in diesem Kapitel erörtern.
Die folgenden Unterabschnitte bieten einen detaillierten Blick auf die verfügbaren Speicherverfahren.
In der anfänglichen Entwurfsphase von Subversion entschieden sich die Entwickler aus einer Reihe von Gründen, Berkeley DB zu verwenden. Hierzu zählen die quelloffene Lizenz, Transaktionsunterstützung, Zuverlässigkeit, Arbeitsleistung, Einfachheit der Programmierschnittstelle, Thread-Sicherheit, Cursor-Unterstützung usw.
Berkeley DB bietet echte Transaktionsunterstützung – vielleicht seine stärkste Funktion. Mehrere Prozesse, die auf Ihre Subversion-Repositorys zugreifen, brauchen sich keine Sorgen machen, dass sie sich versehentlich gegenseitig die Daten zerschießen. Die durch das Transaktiossystem gebotene Isolation bedeutet, dass der Subversion-Repository-Programmcode für jede gegebene Operation eine statische Sicht auf die Datenbank hat – keine sich durch die Einflüsse anderer Prozesse ständig ändernde Datenbank – und basierend auf dieser Sicht Entscheidungen treffen kann. Falls die getroffene Entscheidung zu einem Konflikt damit führt, was eine anderer Prozess macht, wird die gesamte Transaktion zurückgerollt, als wäre sie nie passiert, und Subversion versucht höflich, die Operation mithilfe einer aktualisierten (aber immer noch statischen) Sicht der Datenbank erneut durchzuführen.
Eine weitere großartige Funktion von Berkeley DB sind Hot Backups – die Fähigkeit, die Datenbankumgebung zu sichern, ohne sie „vom Netz“ zu nehmen. Wir besprechen später in diesem Kapitel, wie Sie Ihr Repository sichern (in „Sicherung des Repositorys“), doch sollten die Vorteile offensichtlich sein, die dadurch entstehen, dass Sie vollständige Sicherheitskopien Ihrer Repositorys ohne Wartungszeiträume machen können.
Bei Berkeley DB handelt es sich auch um ein sehr zuverlässiges Datenbanksystem, wenn es richtig verwendet wird. Subversion benutzt das Protokollierungssystem von Berkeley DB, was bedeutet, dass die Datenbank zunächst eine Beschreibung der Veränderungen in Protokolldateien auf der Platte schreibt, bevor die Veränderungen selbst durchgeführt werden. Dies stellt sicher, dass, falls etwas schief geht, die Datenbank zu einem früheren Sicherungspunkt zurückgehen kann – eine Stelle in den Protokolldateien, von der bekannt ist, dass sie eine nicht beschädigte Datenbank bezeichnet – und Transaktionen solange wiederholen kann, bis die Daten sich wieder in einem brauchbaren zustand befinden. Siehe „Plattenplatzverwaltung“ weiter unten in diesem Kapitel für weitere Informationen zu Berkeley-DB-Protokolldateien.
Doch keine Rose ohne Dornen, uns so müssen wir auch einige bekannte Einschränkungen von Berkeley DB ansprechen. Erstens sind Berkeley-DB -Umgebungen nicht portierbar. Sie können nicht einfach ein unter Unix erzeugtes Subversion-Repository auf ein Windows-System kopieren und erwarten, dass es funktioniert. Obwohl ein Großteil des Berkeley-DB-Datenbankformats architekturunabhängig ist, sind es andere Teile der Umgebung nicht. Zweitens benutzt Subversion Berkeley DB auf eine Weise, die nicht auf Windows 95/98 funktioniert – falls Sie ein BDB-basiertes Repository auf einer Windows-Maschine unterbringen müssen, bleiben Sie bei Windows 2000 oder einem seiner Nachfolger.
Obwohl Berkeley DB verspricht, sich korrekt auf freigegebenen Netzlaufwerken zu verhalten, die bestimmte Anforderungen erfüllen, [30] bieten die meisten Netz-Dateisysteme keine derartige Unterstützung. Und keinesfalls dürfen Sie zulassen, dass gleichzeitig von mehreren Clients auf ein BDB-basiertes Repository auf einer Netzfreigabe zugegriffen wird (was eigentlich der Hauptgrund dafür ist, das Repository auf einer Netzfreigabe unterzubringen).
![[Warnung]](images/warning.png)
|
Warnung |
|---|---|
|
Falls Sie versuchen sollten, Berkeley DB auf einem Netz-Dateisystem unterzubringen, das die Anforderungen nicht erfüllt, ist das Ergebnis unvorhersehbar – es kann sein, dass Sie sofort mysteriöse Fehler wahrnehmen oder es kann Monate dauern, bis Sie bemerken, dass Ihre Repository-Datenbank fast unmerklich beschädigt ist. Sie sollten ernsthaft erwägen, das FSFS-Speicherverfahren für Repositorys zu verwenden, die auf einer Netzfreigabe untergebracht werden sollen. |
Schließlich ist Berkeley DB empfindlicher gegenüber Unterbrechungen als ein typisches relationales Datenbanksystem, da es sich um eine Bibliothek handelt, die direkt in Subversion eingebunden ist. Beispielsweise haben die meisten SQL-Systeme einen dedizierten Server-Prozess, der alle Tabellenzugriffe vermittelt. Falls ein auf die Datenbank zugreifendes Programm aus irgendeinem Grund abstürzt, bemerkt der Datenbank-Dämon die verlorene Verbindung und räumt anschließend auf. Und da der Datenbank-Dämon der einzige Prozess ist, der auf die Tabellen zugreift, brauchen sich Anwendungsprogramme nicht um Berechtigungskonflikte zu kümmern. Das trifft allerdings nicht auf Berkeley DB zu. Subversion (und jedes Programm, das die Subversion-Bibliotheken verwendet) greift direkt auf die Datenbanktabellen zu, was bedeutet, dass ein Programmabsturz die Datenbank vorübergehend in einem inkonsistenten, nicht zugreifbaren Zustand hinterlassen kann, so dass ein Administrator Berkeley DB dazu auffordern muss, zu einem Sicherungspunkt zurückzugehen, was etwas ärgerlich ist. Neben abgestürzten Prozessen können andere Dinge das Repository „verklemmen“, wie etwa Programme, die sich wegen Eigentums- und Zugriffsrechten auf Datenbankdateien ins Gehege kommen.
![[Anmerkung]](images/note.png)
|
Anmerkung |
|---|---|
|
Berkeley DB 4.4 bietet (für Subversion 1.4 und spätere Versionen) die Fähigkeit, dass Subversion falls erforderlich automatisch und transparent Berkeley-DB-Umgebungen wiederherstellt. Wenn sich ein Subversion-Prozess an die Berkeley-DB-Umgebung hängt, verwendet er eine Art Prozess-Buchhaltung, um unsaubere Verbindungsabbrüche früherer Prozesse zu entdecken, führt die notwendige Wiederherstellung durch und fährt fort, als wäre nichts passiert. Dies verhindert das Vorkommen von Verklemmungen zwar nicht vollständig, verringert allerdings erheblich den Aufwand an menschlichen Eingriffen, um sich hiervon zu erholen. |
Während ein Berkeley-DB-Repository ziemlich schnell und
skalierbar ist, wird es am besten von einem einzelnen
Server-Prozess unter einer Benutzerkennung verwendet –
so wie Apaches httpd oder
svnserve (siehe Kapitel 6, Die Administration eines Subversion-Servers) – statt darauf mit
mehreren Benutzern über file:// oder
svn+ssh:// URLs zuzugreifen. Falls Sie
mit mehreren Benutzern direkt auf ein Berkeley-DB-Repository
zugreifen wollen, sollten Sie unbedingt „Supporting Multiple Repository Access Methods“ weiter unten in
diesem Kapitel lesen.
Mitte 2004 entstand ein zweiter Typ eines Repository-Speichersystems – eins, das überhaupt keine Datenbank verwendet. Ein FSFS-Repository speichert die zu einer Revision gehörenden Änderungen in einer einzelnen Datei, so dass sich alle Revisionen eines Repositorys in einem Verzeichnis voller nummerierter Dateien befinden. Transaktionen werden als individuelle Dateien in getrennten Verzeichnissen erzeugt. Sobald sie vollständig ist, wird die Transaktionsdatei umbenannt und in das Revisionsverzeichnis verschoben, so dass die Atomizität von Übergaben gewährleistet ist. Und da eine Revisionsdatei dauerhaft und unveränderlich ist, kann das Repository auch im laufenden Betrieb gesichert werden, genauso wie ein BDB-basiertes Repository.
Die FSFS-Revisionsdateien beschreiben die Verzeichnisstruktur einer Revision, Dateiinhalte und Deltas zu Dateien in anderen Revisionsbäumen. Anders als eine Berkeley-DB-Datenbank, ist dieses Speicherformat auf verschiedene Betriebssysteme übertragbar und nicht von einer CPU-Architektur abhängig. Da weder Journaldateien noch Dateien für gemeinsam benutzten Speicher verwendet werden, kann auf das Repository sicher über ein Netzdateisystem zugegriffen und es in einer Nur-Lese-Umgebung untersucht werden. Das Fehlen der Datenbankverwaltung bedeutet ebenfalls eine etwas geringere Größe des Repositorys.
FSFS hat auch eine unterschiedliche Charakteristik, was den Durchsatz anbelangt. Wenn eine große Zahl an Dateien übergeben wird, kann FSFS schneller Verzeichniseinträge hinzufügen. Andererseits schreibt FSFS die letzte Version einer Datei als ein Delta gegenüber einer älteren Version, was bedeutet, dass das Auschecken des letzten Baums etwas langsamer ist als die vollständigen Texte zu holen, die in einer Berkeley-DB HEAD-Revision gespeichert sind. FSFS hat auch eine längere Verzögerung beim Fertigstellen einer Übergabe, was im Extremfall dazu führen kann, dass bei Clients Zeitüberschreitungen beim Warten auf eine Antwort auftreten.
Der wichtigste Unterschied jedoch ist die Unempfänglichkeit von FSFS gegenüber Verklemmungen, wenn etwas schief geht. Falls ein Prozess, der eine Berkeley-DB-Datenbank benutzt, ein Berechtigungsproblem bekommt oder plötzlich abstürzt, kann das die Datenbank in einen unbrauchbaren Zustand bringen, bis ein Administrator sie wiederherstellt. Falls ein Prozess, der ein FSFS-Repository benutzt, in dieselbe Situation gerät, ist das Repository hiervon überhaupt nicht betroffen. Das Schlimmste, was passieren kann, ist, dass einige Transaktionsdaten nicht abgearbeitet werden können.
Das einzige echte Argument, was gegen FSFS spricht, ist seine relative Unreife im Gegensatz zu Berkeley DB. Anders als Berkeley DB, das auf eine jahrelange Geschichte zurückblicken kann, ein eigenes Entwicklerteam hat und sich nun mit dem mächtigen Namen Oracle schmücken darf, [31] ist FSFS eine neuere Technik. Vor Subversion 1.4 purzelten immer noch einige ernsthafte Fehler in Bezug auf die Unversehrtheit der Daten heraus, die, obwohl sie sehr selten ausgelöst wurden, dennoch auftraten. Nichtsdestoweniger ist FSFS schnell zum Speicherverfahren der Wahl für einige der größten öffentlichen und privaten Subversion-Repositorys geworden und verspricht durch die Bank eine niedrigere Einstiegshürde für Subversion.
[27] Ob es an Ignoranz oder an schlecht überlegten Konzepten zur Erstellung berechtigter Metriken für die Software-Entwicklung liegt, ist es dumm, Angst vor globalen Revisionsnummern zu haben, und es ist deshalb kein Kriterium, das Sie heranziehen sollten, wenn Sie abwägen, wie Sie Ihre Projekte und Repositorys anlegen wollen.
[28] Das Trio trunk,
tags, and branches
wird manchmal als „die TTB-Verzeichnisse“
bezeichnet.
[29] Wenn Jack Repenning gefragt wird, ist die Aussprache oft „fass-fass“. (Jedoch geht dieses Buch davon aus, dass der Leser „eff-ess-eff-ess“ denkt)
[30] Berkeley DB setzt voraus, dass das zugrundeliegende Dateisystem strenge POSIX-Sperrmechanismen implementiert und, noch wichtiger, die Fähigkeit mitbringt, Dateien direkt in den Prozessspeicher abzubilden.
[31] Oracle kaufte Sleepycat und sein Vorzeigeprogramm, Berkeley DB, am Valentinstag 2006.