1 Grundlegende Konzepte... 1 Das Repository... 1 Versionierungsmodelle... 2 Subversion in Aktion... 8 Zusammenfassung... 18

Transkript

1

2 First Inhalt Vorwort Einleitung IX XIII 1 Grundlegende Konzepte Das Repository Versionierungsmodelle Subversion in Aktion Zusammenfassung Basisanwendung Hilfe! Daten in Ihr Repository bringen Das erste Auschecken Der grundsätzliche Arbeitsablauf Die History untersuchen Manchmal müssen Sie einfach nur aufräumen Zusammenfassung Fortgeschrittene Themen Revisionsspezifikatoren Eigenschaften Dateiportabilität Unversionierte Objekte ignorieren Schlüsselwortersetzung Teilbäume Sperren Externals-Definitionen This is the Title of the Book, ematter Edition Copyright 2009 O Reilly & Associates, Inc. All rights reserved. Inhalt V

3 Peg-Revisionen und operative Revisionen Änderungslisten Netzwerkmodell Zusammenfassung Links 4 Verzweigen und Zusammenführen Was ist ein Zweig? Zweige verwenden Einfaches Zusammenführen Fortgeschrittenes Zusammenführen Zweige wechseln Tags Die Pflege von Zweigen Häufig verwendete Verzweigungsmuster Herstellerzweige Zusammenfassung Repository-Administration Definition des Subversion-Repository Strategien zum Aufbau eines Repository Erstellen und Konfigurieren Ihres Repository Repository-Erzeugung und -Konfiguration Repository-Wartung Verschieben und Entfernen von Repositories Zusammenfassung Serverkonfiguration Überblick Auswählen einer Serverkonfiguration svnserve: ein eigener Server httpd: Der Apache-HTTP-Server Pfadbasierte Autorisierungen Mehrere Methoden für den Repository-Zugriff unterstützen Anpassen der Subversion-Umgebung Der Laufzeitkonfigurationsbereich Lokalisierung Verwendung externer Editoren Externe Diff- und Merge-Tools Zusammenfassung VI Inhalt This is the Title of the Book, ematter Edition Copyright 2009 O Reilly & Associates, Inc. All rights reserved.

4 Rechts 8 Subversion einbetten Geschichteter Bibliotheksaufbau Im Administrationsbereich der Arbeitskopie Die APIs benutzen Zusammenfassung Vollständige Subversion-Referenz Der Subversion-Kommandozeilenclient svn svnadmin svnlook svnsync svnserve svndumpfilter svnversion mod_dav_svn-konfigurationsanweisungen mod_authz_svn Eigenschaften von Subversion Repository-Hooks A Schnelleinstieg in Subversion B Subversion für CVS-Benutzer C WebDAV und Autoversionierung D Copyright Index This is the Title of the Book, ematter Edition Copyright 2009 O Reilly & Associates, Inc. All rights reserved. Inhalt VII

5 FirstLeft. Kapitel KAPITEL 5 5 Repository-Administration Das Subversion-Repository bildet den zentralen Speicher für all Ihre versionierten Daten. Als solcher ist es ein offensichtlicher Kandidat für die Hege und Pflege eines Administrators. Das Repository ist zwar im Prinzip ein Bereich, der nur geringer Wartung bedarf, aber es ist wichtig zu verstehen, wie man es richtig konfiguriert und betreut, damit potenzielle Probleme vermieden und tatsächliche Probleme sicher gelöst werden können. In diesem Kapitel besprechen wir, wie ein Subversion-Repository erzeugt und konfiguriert wird. Es geht außerdem um die Repository-Wartung mit Beispielen dafür, wie und wann man die Tools svn-look und svnadmin nutzt (die mit Subversion geliefert werden). Wir gehen auf einige häufig auftretende Fragen und Fehler ein und liefern Anregungen, wie die Daten im Repository angeordnet werden können. Falls Sie vorhaben, auf ein Subversion-Repository ausschließlich in der Rolle eines Benutzers zuzugreifen, dessen Daten der Versionskontrolle unterliegen (das heißt, über einen Subversion-Client), dann können Sie dieses Kapitel gleich überspringen. Sind Sie jedoch ein Subversion-Administrator, oder planen Sie, einer zu werden, 1 dann ist dieses Kapitel genau das Richtige für Sie. Definition des Subversion-Repository Bevor wir uns dem umfassenden Thema der Repository-Administration zuwenden, wollen wir erst einmal definieren, was ein Repository ist. Wie sieht es aus? Wie fühlt es sich an? Trinkt es lieber Earl Grey, heiß, oder Eistee, mit Zucker und Milch oder ohne alles? Als Administrator erwartet man von Ihnen, dass Sie den Aufbau eines Repository sowohl 1 Das klingt jetzt vielleicht hochtrabend und pathetisch, wir reden aber einfach über jemanden, der sich eingehender mit diesem mysteriösen Bereich jenseits der Arbeitskopie beschäftigen will, in dem sich die Daten der Benutzer befinden. 162 Kapitel 5: Repository-Administration

6 Rechts aus Betriebssystemsicht verstehen wie sich ein Repository in Bezug auf Subversionfremde Werkzeuge darstellt und wie es agiert, als auch aus logischer Sicht das heißt, wie die Daten im Repository repräsentiert werden. Aus der Sicht einer typischen Dateibrowseranwendung (wie des Windows Explorer) oder von befehlszeilenbasierten Dateisystem-Navigationstools ist das Subversion-Repository nicht mehr als irgendein Verzeichnis mit viel Krempel. Es gibt ein paar Unterverzeichnisse mit für Menschen lesbaren Konfigurationsdateien, ein paar Unterverzeichnisse mit für Menschen nicht ganz so gut lesbaren Datendateien und so weiter. Wie in anderen Bereichen des Subversion-Designs wird Modularität hoch bewertet und die hierarchische Organisation dem wirren Chaos vorgezogen. Ein oberflächlicher Blick in ein typisches Repository reicht daher, um die grundlegenden Komponenten eines Repository zu zeigen: $ ls repos conf/ dav/ db/ format hooks/ locks/ README.txt Es folgt ein kurzer Überblick darüber, was Sie in der Verzeichnisausgabe genau sehen. (Halten Sie sich nicht an den Begriffen auf eine detaillierte Beschreibung dieser Komponenten findet sich in diesem und in anderen Kapiteln.) conf Ein Verzeichnis mit Konfigurationsdateien dav Ein Verzeichnis für die privaten Verwaltungsdaten von mod_dav_svn db Der Speicherort für alle Ihre versionierten Daten format Eine Datei, die eine einzelne Zahl enthält, die die Versionsnummer des Repository- Layouts angibt hooks Ein Verzeichnis mit Hook-Skript-Vorlagen (und den Hook-Skripten selber, sobald Sie welche installiert haben) locks Ein Verzeichnis für die Repository-Sperrdateien von Subversion, die genutzt werden, um die auf das Repository zugreifenden Benutzer zu dokumentieren README.txt Eine Datei, deren Inhalt den Leser schlicht darüber informiert, dass er sich gerade ein Subversion-Repository anschaut Natürlich wird diese ansonsten nicht sehr bemerkenswerte Sammlung von Dateien und Verzeichnissen bei einem Zugriff über die Subversion-Bibliotheken plötzlich eine Implementierung eines virtuellen, versionierten Dateisystems, komplett mit anpassbaren Ereignis-Triggern. Dieses Dateisystem hat seine eigene Vorstellung von Verzeichnissen und Definition des Subversion-Repository 163

7 Dateien, und sie ähneln den Vorstellungen, die echte Dateisysteme davon haben (zum Beispiel NTFS, FAT32, ext3 und so weiter). Aber das hier ist ein besonderes Dateisystem es macht all diese Verzeichnisse und Dateien von Versionen abhängig und verwahrt alle Änderungen, die Sie jemals an ihnen gemacht haben, sicher gespeichert und für immer erreichbar. Hier leben all Ihre versionierten Daten. Strategien zum Aufbau eines Repository Aufgrund der Einfachheit des Gesamtdesigns eines Subversion-Repository und der Technologien, auf denen es basiert, ist das Erstellen und Konfigurieren eines Repository eine ziemlich einfache Angelegenheit. Es gibt ein paar Entscheidungen, die Sie im Voraus treffen sollten, aber die eigentliche Arbeit beim Aufsetzen eines Subversion-Repository ist sehr simpel und wiederholt sich, wenn Sie mehrere davon installieren müssen. Aber einige Dinge, die Sie im Vorhinein zu bedenken haben, sind: Was für Daten werden vermutlich in Ihrem Repository (oder Ihren Repositories) abgelegt werden, und wie werden diese Daten organisiert sein? Wo wird sich Ihr Repository befinden, und wie wird darauf zugegriffen? Was für eine Zugriffskontrolle und Repository-Ereignisprotokollierung brauchen Sie? Welchen der verfügbaren Typen von Datenablagen wollen Sie nutzen? In diesem Abschnitt wollen wir versuchen, Ihnen beim Beantworten dieser Fragen zu helfen. Planen der Repository-Organisation Obwohl Subversion Ihnen ermöglicht, versionierte Dateien und Verzeichnisse ohne Informationsverluste herumzuschieben und sogar erlaubt, ganze Sets versionierter Historys von einem Repository zu einem anderen zu schieben, können solche Aktionen den Arbeitsablauf der Anwender des Repository häufig stark stören, da sie bestimmte Dinge an bestimmten Orten erwarten. Bevor Sie also ein neues Repository erstellen, versuchen Sie ein bisschen in die Zukunft zu blicken planen Sie voraus, bevor Sie Ihre Daten unter Versionskontrolle stellen. Indem Sie Ihr Repository oder Ihre Repositories und ihre versionierten Inhalte gewissenhaft»entwerfen«, können Sie einigen zukünftigen Stress vermeiden. Lassen Sie uns annehmen, dass Sie als Repository-Administrator für die Betreuung des Versionskontrollsystems diverser Projekte zuständig sind. Ihre erste Entscheidung ist, ob Sie ein einzelnes Repository für mehrere Projekte nutzen, ob jedes Projekt sein eigenes Repository bekommt oder ob Sie einen Weg irgendwo dazwischen beschreiten wollen. Ein einzelnes Repository für mehrere Projekte zu nutzen, bietet einige Vorteile, vor allem erspart man sich damit doppelte Wartung. Ein einzelnes Repository bedeutet, dass es eine Gruppe von Hook-Programmen gibt, nur einen Bereich, der regelmäßig zu sichern Links 164 Kapitel 5: Repository-Administration

8 Rechts ist, ein»objekt«, das exportiert und wieder importiert werden muss, wenn Subversion eine inkompatible neue Version herausbringt, und so weiter. Zudem können Sie Daten zwischen Projekten leicht verschieben, ohne irgendwelchen historischen Versionierungsinformationen zu verlieren. Der Nachteil eines einzelnen Repository ist, dass unterschiedliche Projekte auch unterschiedliche Anforderungen in Bezug auf Ereignis-Trigger haben können, wie zum Beispiel, Commit-Benachrichtigungs- s an verschiedene Mailinglisten zu schicken oder unterschiedliche Definitionen davon zu haben, was ein erlaubter Commit ist und was nicht. Das sind natürlich keine unüberwindbaren Probleme es bedeutet nur, dass all Ihre Hook-Skripten genau schauen müssen, wo im Repository sie gerade tätig sind, anstatt annehmen zu können, dass das gesamte Repository mit einer einzigen Personengruppe verbunden ist. Denken Sie auch daran, dass Subversion Revisionsnummern verwendet, die global für das gesamte Repository gelten. Auch wenn diese Nummern keine besondere, magische Bedeutung besitzen, mögen manche Leute einfach nicht, dass selbst ohne neuere Änderungen an ihren Projekten die Revisionsnummer kontinuierlich nach oben klettert, weil andere Projekte aktiv neue Revisionen hinzufügen. 2 Ein Ansatz irgendwo in der Mitte kann genauso verfolgt werden. So können zum Beispiel Projekte danach gruppiert werden, wie sie zueinander in Beziehung stehen. Sie haben vielleicht ein paar Repositories mit einer Hand voll Projekten in jedem Repository. Auf diese Weise können Projekte, die sehr wahrscheinlich Daten gemeinsam nutzen wollen, das einfach erreichen. Und wenn dem Repository neue Revisionen hinzugefügt werden, wissen die Entwickler, dass diese zumindest entfernt mit jedem zu tun haben, der mit diesem Repository arbeitet. Nachdem Sie entschieden haben, wie Ihre Projekte in Bezug auf die Repositories organisiert sind, werden Sie vermutlich über die Verzeichnishierarchien innerhalb der Repositories selbst nachdenken wollen. Da ein Repository normale Verzeichniskopien für das Verzweigen und Taggen nutzt (siehe Kapitel 4), empfiehlt die Subversion-Community, dass Sie einen Repository-Standort für jede Projektbasis nutzen das»oberste«verzeichnis, das Daten dieses Projekts enthält und dann darunter drei Unterverzeichnisse erstellen: trunk, also das Verzeichnis, in dem die Hauptentwicklungslinie des Projekts liegt; branches, das Verzeichnis, in dem verschiedene Zweige von der Hauptentwicklungslinie erstellt werden können; und tags, wobei es sich um eine Sammlung von Momentaufnahmen handelt, die erstellt und vielleicht auch gelöscht, aber niemals geändert werden. 3 2 Egal, ob durch Ignoranz oder schlecht geplante Konzepte über das Bestimmen korrekter Software-Entwicklungsmetriken globale Revisionsnummern muss keiner fürchten, und sie sind definitiv nicht sehr wichtig, wenn es um die Organisation Ihrer Projekte und Repositories geht. 3 Das Trio aus Trunk, Tags und Branches wird manchmal als»die TTB-Verzeichnisse«bezeichnet. Strategien zum Aufbau eines Repository 165

9 Ihr Repository kann zum Beispiel so aussehen: / calc/ trunk/ tags/ branches/ calendar/ trunk/ tags/ branches/ spreadsheet/ trunk/ tags/ branches/ Beachten Sie, dass es keine Rolle spielt, wo in Ihrem Repository sich die einzelnen Projektwurzeln befinden. Falls Sie nur ein Projekt pro Repository haben, erscheint es logisch, jede Projektwurzel an der Wurzel des jeweiligen Repository des Projekts zu platzieren. Bei mehreren Projekten werden Sie diese möglicherweise in Gruppen innerhalb des Repository anordnen, wobei Sie vermutlich Projekte mit ähnlichen Zielsetzungen oder gemeinsamen Codebestandteilen in dasselbe Unterverzeichnis setzen oder sie vielleicht auch einfach alphabetisch gruppieren. Eine solche Anordnung könnte folgendermaßen aussehen: / utils/ calc/ trunk/ tags/ branches/ calendar/ trunk/ tags/ branches/ office/ spreadsheet/ trunk/ tags/ branches/ Gestalten Sie Ihr Repository so, wie es Ihnen passend erscheint. Subversion erwartet oder erzwingt kein bestimmtes Layoutschema in seinen Augen gilt: Ein Verzeichnis ist ein Verzeichnis ist ein Verzeichnis. Letztendlich sollten Sie den Aufbau des Repository so wählen, dass er den Anforderungen der Leute entspricht, die an den dort befindlichen Projekten arbeiten müssen. Um keine Geheimnisse zu verbergen, wollen wir aber auch eine andere weit verbreitete Struktur erwähnen. Dabei befinden sich die Verzeichnisse trunk, tags und branches im Links 166 Kapitel 5: Repository-Administration

10 Rechts Wurzelverzeichnis Ihres Repository, und die Projekte befinden sich in Unterverzeichnissen darunter, zum Beispiel so: / trunk/ calc/ calendar/ spreadsheet/ tags/ calc/ calendar/ spreadsheet/ branches/ calc/ calendar/ spreadsheet/ Diese Struktur ist an sich in Ordnung, aber sie kann für die Anwender mehr oder weniger intuitiv sein. Insbesondere in Situationen mit großen und vielen Projekten sind die Benutzer vermutlich nur mit einem oder zweien dieser Projekte im Repository vertraut. Der»Projekt-als-Geschwisterzweig«-Ansatz tendiert aber eher dazu, die individuellen Projekte in den Hintergrund zu stellen und sich auf den gesamten Satz von Projekten als eine Einheit zu konzentrieren. Das ist natürlich eine soziale Frage. Wir mögen unser zuerst vorgeschlagenes Arrangement aus rein praktischen Gründen: Es ist einfacher, nach der gesamten History eines einzelnen Projekts zu fragen (oder sie zu verändern oder zu verschieben), wenn es einen einzelnen Repository-Pfad gibt, der die gesamte History für dieses Projekt enthält Vergangenheit, Gegenwart, Tags und Zweige und nur für dieses Projekt. Wo und wie wird Ihr Repository verwaltet? Bevor Sie Ihr Subversion-Repository erstellen, ist eine offensichtlich zu beantwortende Frage, wo das Repository überhaupt liegen soll. Diese Frage ist eng mit tausend anderen Fragen verbunden wie das Repository angesprochen werden wird (über einen Subversion- Server oder direkt), von wem (Anwender hinter Ihrer Firmenfirewall oder die ganze Welt über das Internet), welche anderen Services Sie um Subversion herum anbieten (eine Repository-Browsingschnittstelle, -basierte Commit-Benachrichtigungen und so weiter), wie Ihre Backupstrategie aussieht und so weiter. Wir behandeln die Wahl des Servers und die Konfiguration in Kapitel 6, aber wir wollen hier darauf hinweisen, dass die Antworten auf einige dieser Fragen Ihre Entscheidung für die Wahl eines Standorts stark einschränken können. So können es zum Beispiel bestimmte Deployment-Szenarien erfordern, dass das Repository über ein Remote-Dateisystem von Strategien zum Aufbau eines Repository 167

11 mehreren Rechnern aus angesprochen werden kann, wodurch die Wahl einer Repository- Backend-Ablage (die im nächsten Abschnitt behandelt wird) keine Wahl mehr ist, da nur eines der verfügbaren Backends dazu überhaupt in der Lage ist. Alle möglichen Arten zu beschreiben, wie Subversion bereitzustellen ist, ist sowohl unmöglich als auch zu viel für den Rahmen dieses Buches. Wir fordern Sie nur dazu auf, Ihre Optionen anhand dieser Seiten und anderer Quellen zu untersuchen und vorauszuplanen. Wählen einer Datenablage Seit Version 1.1 unterstützt Subversion zwei Optionen für den Typ der zugrunde liegenden Datenablage häufig als»das Backend«oder etwas verwirrend als»das (versionierte) Dateisystem«bezeichnet, die jedes Repository verwendet. Bei der einen Option wird alles in einer Berkeley DB- (oder BDB-)Datenbankumgebung gespeichert. Repositories, die diesen Typ verwenden, werden oft als»bdb-backed«bezeichnet. Der andere Typ speichert Daten in normalen Dateien mit einem eigenen Format. Die Entwickler von Subversion haben den Gebrauch des Begriffs FSFS für diesen Typ Datenablage übernommen 4 eine Implementierung eines versionierten Dateisystems, das das zugrunde liegende OS-Dateisystem direkt nutzt, anstatt die Daten über eine Datenbankbibliothek oder eine andere Abstraktionsschicht abzulegen. Tabelle 5-1 vergleicht Berkeley DB und FSFS als Repository-Grundlagen. Tabelle 5-1: Vergleich der Repository-Datenablage Kategorie Feature Berkeley DB FSFS Zuverlässigkeit Datenintegrität Bei korrekter Installation extrem zuverlässig; mit Berkeley DB 4.4 automatische Wiederherstellung Erreichbarkeit Empfindlichkeit bei Unterbrechungen Von einem schreibgeschützten Mount nutzbar Plattformunabhängige Datenablage Über Netzwerkdateisysteme verwendbar Groß; Abstürze und Berechtigungsprobleme können die Datenbank durcheinander bringen und eine Wiederherstellung erforderlich machen Nein Nein Im Allgemeinen nein Ältere Versionen hatten ein paar selten vorkommende, aber dann datenzerstörende Fehler Recht unempfindlich Ja Ja Ja Links 4 Oft gesprochen als»fuzz-fuzz,«wenn Jack Repenning etwas dazu zu sagen hat. (Dieses Buch geht allerdings davon aus, dass der Leser an»eff-ess-eff-ess«denkt.) 168 Kapitel 5: Repository-Administration

12 Rechts Tabelle 5-1: Vergleich der Repository-Datenablage (Fortsetzung) Kategorie Feature Berkeley DB FSFS Erreichbarkeit Verwendung von Gruppenberechtigungen Reagiert empfindlich auf umask-probleme von Benutzern, am besten nur von einem Benutzer anzusprechen Umgeht umask-probleme Skalierbarkeit Performance Festplattenverbrauch des Repository Höher (insbesondere, wenn Logdateien nicht gelöscht werden) Niedriger Anzahl an Revisionsbäumen Datenbank, kein Problem Einige ältere Dateisysteme skalieren nicht gut bei tausenden von Einträgen in einem einzelnen Verzeichnis Verzeichnisse mit vielen Dateien Langsamer Schneller Auschecken der neuesten Kein echter Unterschied Kein echter Unterschied Revision Große Commits Insgesamt langsamer, aber Aufwand gleichmäßig über den ganzen Commit verteilt Insgesamt schneller, aber die Verzögerung beim Abschluss kann zu einem Timeout beim Client führen Jeder der beiden Backend-Typen hat Vor- und Nachteile. Keiner von beiden ist»offizieller«als der andere, auch wenn das neuere FSFS die Standarddatenablage von Subversion 1.2 ist. Beide sind zuverlässig genug, um ihnen versionierte Daten anzuvertrauen. Aber wie Sie in der Tabelle sehen können, stellt das FSFS-Backend ein bisschen mehr Flexibilität in Bezug auf die unterstützten Installationsszenarien bereit. Mehr Flexibilität heißt, dass Sie sich mehr Mühe geben müssen, es falsch zu installieren. Daraus und aus der Tatsache, dass ein Verzicht auf die Berkeley DB auch bedeutet, dass es eine Komponente weniger im System gibt erklärt sich, warum heutzutage so gut wie jeder das FSFS- Backend nutzt, wenn er neue Repositories erstellt. Glücklicherweise ist den meisten Programmen, die auf Subversion-Repositories zugreifen, völlig schnurz, welche Backend-Datenablage verwendet wird. Und Sie sind auch nicht zwingend an Ihre erste Wahl gebunden falls Sie später Ihre Meinung ändern, stellt Ihnen Subversion Möglichkeiten zur Verfügung, Ihre Repository-Daten in ein anderes Repository zu migrieren, das eine andere Backend-Datenablage nutzt. Wir werden darüber in diesem Kapitel noch sprechen. Die folgenden Unterabschnitte bieten einen genaueren Blick auf die verfügbaren Backend- Datenablagen. Strategien zum Aufbau eines Repository 169

13 Berkeley DB Als die erste Entwurfsphase von Subversion im Gange war, entschieden sich die Entwickler aus unterschiedlichen Gründen für Berkeley DB, unter anderem wegen seiner Open Source-Lizenz, seiner Transaktionsunterstützung, seiner Zuverlässigkeit, der Performanz, der API-Einfachheit, der Threadsicherheit, der Cursorunterstützung usw. Berkeley DB bietet echte Transaktionsunterstützung das ist wahrscheinlich seine stärkste Eigenschaft. Greifen mehrere Prozesse auf Ihre Subversion-Repositorys zu, dann müssen Sie sich keine Sorgen machen, dass diese einander versehentlich die Daten zerstören. Die Isolation, die durch das Transaktionssystem geboten wird, ermöglicht, dass das Subversion-Repository für jede Operation eine statische Sicht der Datenbank erhält nicht einer Datenbank, die sich wegen einiger anderer Prozesse ständig ändert und auf ihrer Basis Entscheidungen treffen kann. Gerät die getroffene Entscheidung in einen Widerspruch mit einer Aktion, die ein anderer Prozess durchführt, wird die gesamte Operation rückgängig gemacht, als wäre sie niemals geschehen, und Subversion versucht, die Operation erneut mit einer neuen, aktualisierten (dabei immer noch statischen) Sicht der Datenbank durchzuführen. Eine andere großartige Eigenschaft von Berkeley DB sind Hot Backups die Fähigkeit, die Datenbankumgebung zu sichern, ohne sie»offline«zu nehmen. Im Abschnitt»Sichern eines Repository«weiter hinten in diesem Kapitel werden wir besprechen, wie Sie Ihr Repository sichern, allerdings sollten Ihre Vorteile auf der Hand liegen, wenn Sie ohne Ausfallzeit voll funktionstüchtige Kopien Ihres Repository anlegen können. Berkeley DB ist außerdem ein sehr zuverlässiges Datenbanksystem, wenn es richtig genutzt wird. Subversion verwendet die Protokollierungsmöglichkeiten von Berkeley DB, was bedeutet, dass die Datenbank zuerst in Protokolldateien auf der Platte eine Beschreibung aller Änderungen ablegt, die durchgeführt werden sollen, bevor es die Veränderungen selbst vornimmt. Damit soll sichergestellt werden, dass das Datenbanksystem im Fehlerfall zu einem früheren Checkpoint einer Stelle in den Protokolldateien, von der bekannt ist, dass sie nicht fehlerhaft ist zurückgehen und Transaktionen erneut durchführen kann, bis die Daten sich wieder in einem benutzbaren Zustand befinden. Im Abschnitt»Festplattenplatz verwalten«weiter hinten in diesem Kapitel finden Sie weitere Informationen über Berkeley DB-Protokolldateien. Doch wo Licht ist, ist auch Schatten. Daher müssen wir Sie auch auf einige bekannte Einschränkungen von Berkeley DB hinweisen. Erstens sind Berkeley DB-Umgebungen nicht portabel. Sie können nicht einfach ein Subversion-Repository, das auf einem Unix-System erzeugt wurde, auf ein Windows-System kopieren und dann erwarten, dass es funktioniert. Ein Großteil des Berkeley DB-Datenbankformats ist zwar architekturunabhängig, es gibt jedoch andere Aspekte der Umgebung, die es nicht sind. Zweitens benutzt Subversion Berkeley DB auf eine Weise, die auf Windows 95/98-Systemen nicht funktioniert falls Sie ein BDB-Backend-Repository auf einem Windows-Rechner vorhalten müssen, sollten Sie Windows 2000 oder neuer verwenden. Links 170 Kapitel 5: Repository-Administration

14 Rechts Die Berkeley DB verspricht zwar, sich auf Netzwerk-Shares korrekt zu verhalten, die bestimmte Spezifikationen erfüllen, 5 die meisten tun das aber eben nicht. Und Sie können einem BDB-Backend-Repository, das auf einem Netzwerk-Share liegt, niemals erlauben, von mehreren Clients gleichzeitig angesprochen zu werden (was oft gerade der Hauptgrund dafür ist, das Repository auf einen Share zu legen). Wenn Sie versuchen, die Berkeley DB auf einem nichtkompatiblen entfernten Dateisystem zu verwenden, sind die Ergebnisse nicht vorhersagbar es kann sein, dass Sie direkt seltsame Fehlermeldungen erhalten, oder es kann Monate dauern, bevor Sie feststellen, dass Ihre Repository-Datenbank subtile Fehler enthält. Sie sollten sich ernsthaft überlegen, die FSFS-Datenablage für Repositories zu nutzen, die auf einem Netzwerk-Share liegen müssen. Da Berkeley DB eine Bibliothek ist, die direkt in Subversion gelinkt ist, reagiert es schließlich deutlich empfindlicher auf Unterbrechungen als ein typisches relationales Datenbanksystem. Die meisten SQL-Systeme haben zum Beispiel einen dedizierten Serverprozess, der sich um alle Zugriffe auf Tabellen kümmert. Wenn ein Programm, das auf die Datenbank zugreift, aus irgendeinem Grund abstürzt, bemerkt der Datenbank-Daemon die»verlorene«verbindung und räumt hinter ihr auf. Und da der Datenbank-Daemon der einzige Prozess ist, der auf die Tabellen zugreift, müssen sich Anwendungen nicht um Berechtigungskonflikte kümmern. Das alles gibt es bei der Berkeley DB nicht. Subversion (und Programme, die Subversion-Bibliotheken nutzen) greift direkt auf die Datenbank zu. Ein abstürzendes Programm kann also die Datenbank in einem vorübergehend inkonsistenten Zustand zurücklassen, in dem sie nicht ansprechbar ist. Geschieht so etwas, muss ein Administrator die Berkeley DB bitten, sich an einem Checkpoint wiederherzustellen, was recht nervig sein kann. Neben abstürzenden Prozessen können auch andere Sachen dazu führen, dass ein Repository»seltsam«wird, wie zum Beispiel Programme, die sich über Besitzer und Berechtigungen der Datenbankdateien nicht im Klaren sind. Berkeley DB 4.4 ermöglicht es (ab Subversion 1.4), Berkeley-DB-Umgebungen automatisch und transparent wiederherzustellen, wenn es notwendig ist. Wenn ein Subversion-Prozess auf die Berkeley-DB-Umgebung eines Repository zugreift, nutzt es gewisse Protokollmechanismen, um festzustellen, ob frühere Prozesse nicht aufgeräumt haben. In solchen Fällen werden die notwendigen Wiederherstellungsmaßnahmen durchgeführt, und dann wird so weitergemacht, als ob nichts geschehen sei. Damit werden durcheinandergebrachte Repositories nicht vollständig ausgeschlossen, aber der Aufwand für Administratoren wird drastisch reduziert, sie wieder herzustellen. 5 Berkeley DB fordert vom zugrunde liegenden Dateisystem eine Implementierung strikter POSIX-Sperrsemantiken und, noch wichtiger, die Fähigkeit, Dateien direkt in den Prozessspeicher abzubilden. Strategien zum Aufbau eines Repository 171

15 Während also ein Repository unter Berkeley DB ziemlich schnell und gut skalierbar ist, wird es doch am besten von einem einzelnen Serverprozess genutzt, der von einem Benutzer ausgeführt wird wie zum Beispiel httpd von Apache oder svnserve (siehe Kapitel 6), anstatt ihn von vielen verschiedenen Benutzern über URLs der Form file:\\ oder svn+ssh:// anzusprechen. Wenn Sie mit mehreren Benutzern direkt auf ein Berkeley DB Repository zugreifen, stellen Sie sicher, dass Sie vorher»mehrere Methoden für den Repository-Zugriff unterstützen«in Kapitel 6 gelesen haben. FSFS Mitte 2004 entstand ein zweiter Typ eines Repository-Speichersystems eines, das überhaupt keine Datenbank nutzt. Ein FSFS-Repository legt die mit einer Revision verbundenen Änderungen in einer einzigen Datei ab, und alle Revision eines Repository finden sich in einem Unterverzeichnis voll mit nummerierten Dateien. Transaktionen werden in eigenen Unterverzeichnissen als einzelne Dateien erstellt. Wenn eine Transaktion abgeschlossen ist, wird die Datei umbenannt und in das Revisionsverzeichnis verschoben, womit garantiert ist, dass die Commits atomar sind. Und da eine Revisionsdatei dauerhaft und unverändert bleibt, kann das Repository auch gesichert werden, ohne Prozesse stoppen zu müssen genau wie ein BDB-Repository. Die FSFS-Revisionsdateien beschreiben die Verzeichnisstruktur einer Revision, die Dateiinhalte und Deltas gegenüber Dateien in anderen Revisionsbäumen. Anders als eine Berkeley DB-Datenbank ist das über unterschiedliche Betriebssysteme hinweg portabel und auch nicht auf eine CPU-Architektur eingeschränkt. Da keine Journaling- oder Shared- Memory-Dateien verwendet werden, kann man auf das Repository sicher über ein Netzwerkdateisystem zugreifen und es in schreibgeschützen Umgebungen lesen. Der fehlende Datenbank-Overhead führt zudem dazu, dass die Gesamtgröße des Repository ein bisschen kleiner ist. FSFS hat zudem andere Performance-Charakteristiken. Wenn ein Verzeichnis mit einer großen Anzahl von Dateien eingecheckt wird, kann FSFS Verzeichniseinträge schneller anfügen. Andererseits schreibt FSFS die neueste Version einer Datei als Delta gegenüber einer früheren Version, was bedeutet, dass das Auschecken des neuesten Baumes ein bisschen langsamer ist als das Auslesen des Volltextes, der in einer Berkeley DB HEAD-Revision gespeichert ist. FSFS hat auch eine größere Verzögerung, wenn ein Commit abgeschlossen wird, was im Extremfall dazu führen kann, dass bei Clients ein Timeout zuschlägt, während sie auf eine Antwort warten. Der wichtigste Unterschied ist aber, dass FSFS stabil gegenüber Verwerfungen ist, wenn etwas schiefgeht. Wenn ein Prozess, der eine Berkeley-DB-Datenbank nutzt, ein Berechtigungsproblem hat oder plötzlich abstürzt, kann die Datenbank in einem nicht mehr nutzbaren Zustand zurückbleiben, bis sich ein Administrator der Sache annimmt. Wenn das gleiche Szenario mit einem Prozess geschieht, der ein FSFS-Repository nutzt, ist das Repository nicht betroffen. Im schlimmsten Fall bleiben ein paar Transaktionsdaten zurück. Links 172 Kapitel 5: Repository-Administration

16 Rechts Das einzige echte Argument gegen FSFS: Es ist noch nicht so reif wie Berkeley DB. Anders als Berkeley DB, das auf eine langjährige Entwicklung zurückblicken kann, ein eigenes Entwicklungsteam besitzt und nun mit Oracles mächtigem Namen verbunden ist, 6 ist FSFS eine neuere Entwicklung. Vor Subversion 1.4 hatte es noch ein paar wirklich ernsthafte Datenintegritätsprobleme, die zwar nur selten auftraten, aber eben vorhanden waren. Trotzdem wurde FSFS schnell das Backend der Wahl für einige der größten öffentlichen und privaten Subversion-Repositories, und es verspricht eine niedrigere Einstiegshürde für Subversion selbst. Erstellen und Konfigurieren Ihres Repository Weiter oben in diesem Kapitel (in»strategien zum Aufbau eines Repository«) haben wir einige der wichtigen Entscheidungen aufgeführt, die getroffen werden sollten, bevor Sie Ihr Subversion-Repository erstellen und konfigurieren. Jetzt sind wir endlich bereit, uns ins Abenteuer zu stürzen! In diesem Abschnitt werden Sie erfahren, wie man ein Subversion-Repository erstellt und es so konfiguriert, dass es bestimmte Aktionen durchführt, wenn besondere Repository-Ereignisse auftreten. Repository-Erzeugung und -Konfiguration Das Erzeugen eines Subversion-Repository ist unglaublich einfach. Das Dienstprogramm svnadmin, das mit Subversion geliefert wird, enthält genau dafür einen Unterbefehl (svnadmin create). $ # Erstelle ein Repository $ svnadmin create /var/svn/repos $ Damit wird ein neues Repository im Verzeichnis /var/svn/repos mit der Standard-Dateisystemdatenablage erstellt. Vor Subversion 1.2 war der Standard Berkeley DB, nun ist es FSFS. Sie können den Dateisystemtyp explizit mit dem Argument --fs-type festlegen, das als Parameter entweder fsfs oder bdb erwartet: $ # Erstelle ein FSFS-backed-Repository $ svnadmin create --fs-type fsfs /var/svn/repos $ $ # Erstelle ein Berkeley-DB-backed-Repository $ svnadmin create --fs-type bdb /var/svn/repos $ Nach dem Ausführen dieses einfachen Befehls haben Sie ein Subversion-Repository. 6 Oracle hat Sleepycat und seine wichtigste Software Berkeley DB am Valentinstag 2006 gekauft. Repository-Erzeugung und -Konfiguration 173

17 Links Der Pfad, der an svnadmin übergeben wird, ist einfach ein normaler Dateisystempfad und keine URL wie die, die das Clientprogramm svn nutzt, um ein Repository anzugeben. Sowohl svnadmin als auch svnlook sind als serverseitige Tools gedacht sie werden auf dem Rechner verwendet, auf dem sich das Repository befindet, um Elemente davon zu analysieren oder zu verändern, und sie sind auch tatsächlich nicht dazu in der Lage, ihre Aufgaben über das Netz auszuführen. Ein gern gemachter Fehler von Subversion-Einsteigern ist, zu versuchen, diesen beiden Programmen eine URL mitzugeben (selbst»lokale«file://-urls). Im Unterverzeichnis db/ Ihres Repository findert sich die Implementierung des versionierten Dateisystems. Dieses beginnt mit der Revision 0, die laut Definition nichts weiter enthält als das oberste Verzeichnis root (/). Anfänglich besitzt Revision 0 außerdem eine einzige Revisionseigenschaft, svn:date, die auf den Zeitpunkt gesetzt ist, zu dem das Repository erzeugt wurde. Jetzt haben Sie ein Repository, und es ist an der Zeit, es zu konfigurieren. Einige Teile eines Subversion-Repository wie die Konfigurationsdateien und die Hook-Skripten sind durchaus dafür gedacht, direkt betrachtet und angepasst zu werden, aber Sie sollten sich davor hüten, mit den anderen Teilen des Repository manuell herumzuspielen. Das Tool svnadmin sollte für alle Änderungen ausreichend sein, die Sie an Ihrem Repository vornehmen müssen. Ansonsten können Sie auch nach Tools von Fremdherstellern Ausschau halten (wie zum Beispiel die Toolsuite von Berkeley DB), um bestimmte Bereiche des Repository anzupassen. Versuchen Sie nicht, manuelle Modifikationen Ihrer Versionskontroll-History vorzunehmen, indem Sie direkt an den Datenablagendateien Ihres Repository drehen! Repository Hooks implementieren Ein Hook ist ein Programm, das von einem Repository-Ereignis ausgelöst wird, etwa von der Erstellung einer neuen Revision oder der Veränderung einer unversionierten Eigenschaft. Manche Hooks (die sogenannten»pre-hooks«) werden vor einer Repository- Operation ausgeführt und sind dafür gedacht, sowohl zu berichten, was geschehen soll, als auch, es zu verhindern. Andere Hooks (die»post-hooks«) laufen nach dem Abschluss eines Repository-Ereignisses und sind nützlich, um Aufgaben auszuführen, die das Repository untersuchen aber nicht verändern. Jedem Hook werden ausreichend Informationen übergeben, die angeben, um welches Ereignis es sich handelt(e), welche Repository- Änderungen umgesetzt werden sollen (oder wurden) und welchen Benutzernamen die Person besitzt, die das Ereignis ausgelöst hat. Im hooks-unterverzeichnis befinden sich standardmäßig bereits Vorlagen für verschiedene Repository-Hooks: 174 Kapitel 5: Repository-Administration

18 Rechts $ ls repos/hooks/ post-commit.tmpl post-unlock.tmpl pre-revprop-change.tmpl post-lock.tmpl pre-commit.tmpl pre-unlock.tmpl post-revprop-change.tmpl pre-lock.tmpl start-commit.tmpl $ Es gibt eine Vorlage für jeden Hook, den das Subversion-Repository unterstützt. Die Inhalte dieser Vorlagenskripten geben Aufschluss darüber, wodurch die einzelnen Skripten ausgelöst werden und welche Daten an das Skript übergeben werden. In vielen dieser Vorlagen finden Sie außerdem Beispiele dafür, wie Sie diese Skripten zusammen mit anderen mit Subversion gelieferten Programmen einsetzen können, um nützliche Aufgaben auszuführen. Um tatsächlich einen funktionierenden Hook zu installieren, müssen Sie einfach nur ein ausführbares Programm oder Skript im Verzeichnis repos/hooks platzieren, das dann unter dem Namen des Hook (wie start-commit oder post-commit) ausgeführt werden kann. Auf Unix-Plattformen bedeutet das, dass Sie ein Skript oder Programm liefern (etwa ein Shell-Skript, ein Python-Programm, ein kompiliertes C-Binary oder eine Reihe anderer Sachen), das genau wie der Name des Hook heißt. Natürlich sollen die Vorlagendateien mehr als nur zur Information dienen die einfachste Möglichkeit, einen Hook auf Unix- Plattformen zu installieren, besteht darin, die entsprechende Vorlagendatei in eine neue Datei zu kopieren, wobei Sie beim Namen dieser Datei dann die Erweiterung.tmpl weglassen, den Inhalt des Hook anpassen und dafür sorgen, dass das Skript ausführbar ist. Windows dagegen verwendet Dateierweiterungen, um festzustellen, ob ein Programm ausführbar ist. Sie müssten deshalb ein Programm angeben, dessen Basisname der Name des Hook ist und bei dessen Erweiterung es sich um eine der Erweiterungen handelt, die von Windows für ausführbare Programme akzeptiert werden, wie.exe für Programme und.bat für Batch-Dateien. Aus Sicherheitsgründen führt das Subversion-Repository Hook-Programme in einer leeren Umgebung aus es sind also keine Umgebungsvariablen gesetzt, nicht einmal $PATH (oder %PATH% unter Windows). Daher sind viele Administratoren verwirrt, wenn ihre Hook-Programme bei der direkten Ausführung wunderbar laufen, aber nicht funktionieren, wenn sie von Subversion ausgeführt werden. Stellen Sie sicher, dass alle notwendigen Umgebungsvariablen in Ihren Hook-Programmen explizit gesetzt sind und/oder dass Sie absolute Pfadangaben verwenden. Subversion führt Hooks als der Benutzer aus, dem auch der Prozess gehört, der auf das Subversion-Repository zugreift. In den meisten Fällen wird auf das Repository über einen Subversion-Server zugegriffen, so dass dieser Benutzer identisch ist mit der Benutzerkennung, unter der der Server auf dem System läuft. Die Hooks selbst müssen mit Berechtigungen auf Betriebssystemebene konfiguriert werden, die es diesem Benutzer erlauben, die Hooks auszuführen. Das bedeutet auch, dass auf alle Programme oder Dateien (einschließlich des Subversion-Repository), auf die der Hook direkt oder indirekt zugreift, Repository-Erzeugung und -Konfiguration 175

19 vom selben Benutzer zugegriffen wird. Mit anderen Worten, achten Sie auf mögliche Probleme, die mit den Berechtigungen zusammenhängen und verhindern können, dass der Hook die Aufgaben ausführt, für die er gedacht ist. Es gibt eine ganze Reihe von Hooks, die durch das Subversion-Repository implementiert werden, und Sie können die Details dazu in Kapitel 9, Vollständige Subversion-Referenz, nachlesen. Als Repository-Administrator müssen Sie sich entscheiden, welche Hooks Sie wie implementieren möchten (indem Sie ein passend benanntes und mit den korrekten Berechtigungen versehenes Hook-Programm bereitstellen). Wenn Sie diese Entscheidung treffen, denken Sie auch daran, wie Ihr Repository bereitgestellt wird. Wenn Sie zum Beispiel die Serverkonfiguration nutzen, um zu bestimmen, welche Benutzer dazu berechtigt sind, Änderungen in Ihr Repository einzuchecken, brauchen Sie diese Form der Zugriffskontrolle nicht über das Hook-System umzusetzen. Es gibt eine große Menge von Subversion-Hook-Programmen und Skripten, die entweder über die Subversion-Community oder von anderen Stellen frei verfügbar sind. Diese Skripten decken einen großen Bereich von Tools ab grundlegende Zugriffskontrolle, Einhaltung von Richtlinien, Integration von Bugtracking-Systemen, Benachrichtigung per oder RSS-Feed und so weiter. Und wenn Sie Ihre eigenen Hooks schreiben wollen, werfen Sie einen Blick in Kapitel 8. Man kann mit Hook-Skripten zwar fast alles umsetzen, aber es gibt einen Bereich, in dem sich Autoren von Hook-Skripten in Zurückhaltung üben sollten: Verändern Sie keine Commit-Transaktionen mit Hook-Skripten. Auch wenn es verführerisch sein mag, mit Hook-Skripten automatisch Fehler oder Verletzungen von Richtlinien zu korrigieren, die in den einzucheckenden Dateien gefunden werden, kann das zu Problemen führen. Subversion hält auf Clientseite Teile der Repository-Daten in Caches vor, und wenn Sie eine Commit-Transaktion auf diese Art und Weise ändern, werden diese Caches verfälscht, ohne dass Sie es bemerken. Diese Inkonsistenz kann zu überraschenden und nicht erwarteten Verhaltensweisen führen. Anstatt die Transaktion zu verändern, sollten Sie sie einfach nur im Hook pre-commit überprüfen, und sie zurückweisen, wenn sie nicht die gewünschten Anforderungen erfüllt. Als Bonus werden Ihre Anwender lernen, dass es sich lohnt, die Arbeit sorgfältig auszuführen. Links Berkeley DB-Konfiguration Eine Berkeley DB-Umgebung ist eine Kapselung einer oder mehrerer Datenbanken, Protokolldateien und Konfigurationsdateien. Die Berkeley DB-Umgebung besitzt ihre eigene Menge von vorgegebenen Konfigurationswerten für Sachen wie die Anzahl der Datenbanksperren, die zu einem beliebigen Zeitpunkt ausgegeben werden, oder die maximale Größe der Journaling-Protokolldateien usw. Die Dateisystemlogik von Subversion legt zusätzliche Standardwerte für einige der Berkeley DB-Konfigurationsoptionen fest. 176 Kapitel 5: Repository-Administration

20 Rechts Manchmal jedoch verlangt Ihr spezielles Repository mit seiner einmaligen Sammlung von Daten und Zugriffsmustern eine andere Menge von Konfigurationsoptionswerten. Die Hersteller von Berkeley DB wissen, dass unterschiedliche Anwendungen und Datenbankumgebungen unterschiedliche Anforderungen stellen. Sie haben deshalb einen Mechanismus zur Verfügung gestellt, mit dem sich zur Laufzeit viele der Konfigurationswerte für die Berkeley DB-Umgebung überschreiben lassen. BDB prüft, ob im Umgebungsverzeichnis (also dem Unterverzeichnis db des Repository) eine Datei namens DB_CONFIG vorhanden ist, und parst die darin enthaltenen Optionen. Subversion selbst erzeugt diese Datei, wenn es den Rest des Repository anlegt. Die Datei enthält anfänglich einige Standardoptionen sowie Verweise auf die Berkeley DB-Onlinedokumentation, so dass Sie nachlesen können, was diese Optionen tun. Natürlich steht es Ihnen frei, beliebige der unterstützten Berkeley DB-Optionen zu Ihrer DB_CONFIG-Datei hinzuzufügen. Vermeiden Sie allerdings Konfigurationsänderungen, durch die sich Berkeley DB auf eine Weise verhält, die für den Rest des Subversion-Codes unerwartet ist, da Subversion niemals versucht, den Inhalt der Datei zu lesen oder zu interpretieren, und die Optionseinstellungen niemals direkt verwendet. Änderungen an DB_CONFIG werden außerdem erst dann wirksam, wenn Sie die Datenbankumgebung wiederherstellen (mit svnadmin recover). Repository-Wartung Die Wartung eines Subversion-Repository kann entmutigend sein, vor allem wegen der Komplexität, die Systemen mit Datenbank-Backend innewohnt. Um die Aufgabe gut zu erledigen, ist es erforderlich, die Werkzeuge zu kennen welche es sind, wann sie eingesetzt werden und wie man sie benutzt. Dieser Abschnitt stellt Ihnen die Werkzeuge zur Repository-Administration vor, die von Subversion bereitgestellt werden, und zeigt Ihnen, wie Sie sie handhaben, um Aufgaben wie Repository-Migrationen, Upgrades, Sicherungen und Aufräumarbeiten durchzuführen. Der Werkzeugkasten eines Administrators Subversion stellt einige Dienstprogramme zur Verfügung, die sich für das Anlegen, Untersuchen, Verändern und Reparieren Ihres Repository eignen. Wir wollen uns diese Werkzeuge einmal näher anschauen. Anschließend werden wir kurz auf einige der Hilfsprogramme aus der Berkeley DB-Distribution eingehen, deren Funktionalität speziell für das Datenbank-Backend Ihres Repository gedacht ist und ansonsten nicht von den Subversion-eigenen Werkzeugen bereitgestellt wird. Repository-Wartung 177

21 svnadmin Das Programm svnadmin ist der beste Freund des Repository-Administrators. Neben der Fähigkeit, Subversion-Repositories anzulegen, erlaubt Ihnen das Programm, verschiedene Wartungsaufgaben auf diesen Repositories auszuführen. Die Syntax von svnadmin ähnelt der anderer Subversion-Befehlszeilenprogramme: $ svnadmin help general usage: svnadmin SUBCOMMAND REPOS_PATH [ARGS & OPTIONS ] Type 'svnadmin help <subcommand>' for help on a specific subcommand. Type 'svnadmin --version' to see the program version and FS modules. Available subcommands: crashtest create deltify Weiter oben in diesem Kapitel (in»repository-erzeugung und -Konfiguration«) haben wir bereits den svnadmin-unterbefehl create vorgestellt. Die meisten anderen werden wir später in diesem Kapitel genauer besprechen und Sie können in»svnadmin«in Kapitel 9 alle Unterbefehle nachlesen. svnlook svnlook ist ein von Subversion bereitgestelltes Werkzeug zum Untersuchen der verschiedenen Revisionen und Transaktionen (also Revisionen, die gerade verarbeitet werden) in einem Repository. Kein Teil dieses Programms versucht, das Repository zu ändern. svnlook wird typischerweise von den Repository-Hooks eingesetzt, um über die Änderungen zu berichten, die dem Repository bestätigt werden sollen (im Fall des pre-commit- Hook) oder gerade bestätigt wurden (im Fall des post-commit-hook). Ein Repository- Administrator könnte dieses Werkzeug für die Diagnose einsetzen. svnlook hat eine sehr einfache Syntax: $ svnlook help general usage: svnlook SUBCOMMAND REPOS_PATH [ARGS & OPTIONS ] Note: any subcommand which takes the '--revision' and '--transaction' options will, if invoked without one of those options, act on the repository's youngest revision. Type 'svnlook help <subcommand>' for help on a specific subcommand. Type 'svnlook --version' to see the program version and FS modules. Die meisten Unterbefehle von svnlook können entweder auf einem Revisions- oder einem Transaktionsbaum arbeiten, wobei sie Informationen über den Baum selbst ausgeben oder darüber, wie sich dieser von der vorherigen Revision des Repository unterscheidet. Mit den Optionen --revision (-r) und --transaction (-t) legen Sie fest, welche Revision bzw. Transaktion untersucht werden soll. Fehlt sowohl die Option --revision (-r) als auch die Option --transaction (-t), dann untersucht svnlook die neueste (oder HEAD-) Links 178 Kapitel 5: Repository-Administration

22 Rechts Revision im Repository. Die folgenden beiden Befehle führen daher genau die gleiche Aktion aus, wenn es sich bei 19 um die neueste Revision im Repository handelt, das unter /var/svn/repos zu finden ist: $ svnlook info /var/svn/repos $ svnlook info /var/svn/repos -r 19 Eine Ausnahme zu diesen Regeln über Unterbefehle bildet der Unterbefehl svnlook youngest, der keine Optionen entgegennimmt und einfach nur die neueste Revisionsnummer ausgibt. $ svnlook youngest /var/svn/repos 19 $ Vergessen Sie nicht, dass Sie nur nicht bestätigte Transaktionen untersuchen können. Die meisten Repositories werden solche Transaktionen gar nicht haben, da Transaktionen normalerweise entweder bestätigt sind (womit Sie sie als Revisionen mit der Option --revision (-r) ansprechen können) oder abgebrochen und entfernt wurden. Die Ausgabe von svnlook ist so gestaltet, dass sie sowohl von Menschen als auch von Computern verstanden werden kann. Nehmen Sie als Beispiel die Ausgabe des Unterbefehls info von svnlook: $ svnlook info /var/svn/repos sally :29: (Mon, 04 Nov 2002) 27 Added the usual Greek tree. $ Die Ausgabe von svnlook info besteht aus den folgenden Informationen in der angegebenen Reihenfolge: 1. Der Autor, gefolgt von einem Zeilenumbruch (Newline) 2. Das Datum, gefolgt von einem Zeilenumbruch (Newline) 3. Die Anzahl der Zeichen in der Protokollmeldung, gefolgt von einem Zeilenumbruch (Newline) 4. Die Protokollmeldung selbst, gefolgt von einem Zeilenumbruch (Newline) Diese Ausgabe ist für Menschen lesbar, das heißt, Objekte wie der Datumsstempel werden als Text dargestellt und nicht als etwas völlig Obskures (wie die Anzahl der Nanosekunden seit der letzten Pizzalieferung). Diese Ausgabe ist aber auch rechnerlesbar da die Protokollmeldung mehrere Zeilen enthalten kann und in der Länge unbegrenzt ist, gibt svnlook die Länge dieser Nachricht vor der Nachricht selbst an. Das erlaubt Skripten Repository-Wartung 179