Versionskontrolle mit Subversion

C. Michael Pilato

Ben Collins-Sussman

Brian W. Fitzpatrick

Published by O’Reilly Verlag

Vorwort

Eine schlechte Liste mit häufig gestellten Fragen (Frequently Asked Questions, FAQ) besteht nicht aus den Fragen, die die Leute tatsächlich gestellt haben, sondern aus den Fragen, von denen sich der Autor der FAQ wünscht, dass die Leute sie gestellt hätten. Sie haben diese Art vielleicht bereits gesehen:

F: Wie kann ich mithilfe von Glorbosoft XYZ die Produktivität unseres Teams steigern?

A: Viele unserer Kunden wollen wissen, wie sie die Produktivität durch den Einsatz unserer patentierten Office-Groupware-Innovationen maximieren können. Die Antwort ist ganz einfach: Klicken Sie zuerst auf das Menü DATEI, scrollen Sie nach unten zum Menüpunkt PRODUKTIVITÄT STEIGERN, und ...

Das Problem bei solchen FAQs besteht darin, dass es sich im Wortsinne überhaupt nicht um FAQs handelt. Niemand würde eine technische Hotline anrufen und fragen: »Wie können wir die Produktivität steigern?«. Stattdessen fragen die Leute nach ganz speziellen Dingen wie: »Wie können wir das Kalendersystem so anpassen, dass wir bereits zwei Tage im Voraus Erinnerungen verschicken können, anstatt nur einen Tag im Voraus?« usw. Es ist aber natürlich viel einfacher, eine Liste mit imaginären häufig gestellten Fragen aufzustellen, als die echten Fragen zu entdecken. Das Zusammenstellen einer echten FAQ-Liste erfordert eine konzentrierte, organisierte Anstrengung: Während der gesamten Lebensdauer einer Software müssen eingehende Fragen geprüft, Antworten überwacht und alles zu einem kohärenten, durchsuchbaren Ganzen zusammengefasst werden, das die kollektive Erfahrung der Benutzer widerspiegelt. Diese Arbeit schreit nach der geduldigen, aufmerksamen Haltung eines Feldforschers. Keine großen Hypothesen, keine visionären Verkündigungen – hier sind einfach nur offene Augen und genaues Hinhören erforderlich.

Ich mag an diesem Buch besonders, dass es aus genau einem solchen Prozess heraus entstanden ist und das auch auf jeder Seite zeigt. Es ist das direkte Ergebnis der Begegnungen der Autoren mit den Benutzern. Alles begann mit der Beobachtung von Ben Collins-Sussman, dass die Leute über die Subversion-Mailinglisten immer wieder die gleichen Fragen stellten: Wie sehen die Standardarbeitsabläufe bei der Benutzung von Subversion aus? Funktionieren Zweige und Tags auf die gleiche Weise wie bei anderen Versionskontrollsystemen? Wie kann ich feststellen, wer eine bestimmte Änderung vorgenommen hat?

Ben, der frustriert darüber war, jeden Tag die gleichen Fragen zu sehen, arbeitete im Sommer 2002 mehr als einen Monat lang intensiv an The Subversion Handbook, einem sechzigseitigen Handbuch, das die Grundlagen der Benutzung von Subversion behandelt. Das Handbuch war bei Weitem nicht vollständig, aber es wurde mit Subversion verteilt und erleichterte den Benutzern den Einstieg. Als O’Reilly beschloss, ein ganzes Subversion-Buch zu veröffentlichen, war der Weg des geringsten Widerstands offensichtlich: Das Subversion-Handbuch musste einfach erweitert werden.

Den drei Koautoren des neuen Buches bot sich eine ungewöhnliche Möglichkeit. Offiziell bestand ihre Aufgabe darin, ein Buch top-down herunterzuschreiben, beginnend beim Inhaltsverzeichnis und einem ersten Entwurf. Sie hatten aber auch Zugang zu einem ständigen Strom – genauer gesagt, zu einem unkontrollierbaren Geysir – weiteren Quellmaterials. Subversion befand sich bereits in den Händen tausender »Early Adopters«, und diese Benutzer lieferten Unmengen an Rückmeldungen, nicht nur über Subversion, sondern auch über seine bestehende Dokumentation.

Während der gesamten Zeit, in der sie an dem Buch schrieben, trieben sich Ben, Mike und Brian unaufhörlich auf den Subversion-Mailinglisten und in den Chaträumen herum und gingen sorgfältig auf die Probleme ein, die Benutzer bei der täglichen Arbeit mit Subversion hatten. Das Überwachen solcher Rückmeldungen gehörte sowieso zu ihren Aufgaben bei CollabNet und bot ihnen einen riesigen Vorteil bei der Dokumentation von Subversion. Das Buch, das daraus entstanden ist, gründet sich auf den Fels der Erfahrung und nicht auf den Treibsand des Wunschdenkens; es kombiniert die besten Aspekte eines Benutzerhandbuches und einer FAQ-Liste. Diese Dualität ist beim ersten Lesen vielleicht nicht zu bemerken. Liest man es einfach von vorn bis hinten durch, dann ist dieses Buch lediglich eine Beschreibung einer Software. Es gibt einen Überblick, die obligatorische geführte Tour, das Kapitel über die administrative Konfiguration, einige Themen für Fortgeschrittene und natürlich eine Befehlsreferenz und Hinweise zur Fehlersuche. Erst wenn Sie später darauf zurückkommen, weil Sie die Lösung für ein bestimmtes Problem suchen, schimmert seine Authentizität durch: die vielsagenden Einzelheiten, die nur aus der Begegnung mit dem Unerwarteten resultieren können, die Beispiele, die ihren Ursprung in echten Anwendungsfällen haben, und vor allem das Wissen um die Bedürfnisse und Sichtweisen der Benutzer.

Natürlich kann niemand versprechen, dass dieses Buch alle Fragen beantworten wird, die Sie in Bezug auf Subversion haben. Manchmal scheint die Genauigkeit, mit der Ihren Fragen vorgegriffen wird, geradezu telepathisch zu sein, gelegentlich jedoch stoßen Sie auf eine Lücke im Wissen der Gemeinschaft und bleiben mit leeren Händen zurück. Wenn das geschieht, dann schicken Sie am besten eine E-Mail an users@subversion.tigris.org und stellen Ihr Problem dar. Die Autoren sind immer noch dort und beobachten die Szene, und es sind nicht nur die drei, die auf dem Buchumschlag stehen, sondern viele weitere, die Korrekturen und Originalmaterial geliefert haben. Aus Sicht der Gemeinschaft ist das Lösen Ihres Problems lediglich eine erfreuliche Nebenwirkung eines viel größeren Projekts – nämlich der Anpassung dieses Buches und schließlich von Subversion selbst an die Art und Weise, wie die Leute es tatsächlich benutzen. Sie sind begierig, von Ihnen zu hören – nicht nur, weil sie Ihnen helfen können, sondern, weil Sie ihnen helfen. Mit Subversion, wie mit allen produktiven freien Softwareprojekten, sind Sie nicht allein.

Dieses Buch soll Ihr erster Begleiter sein.

Karl Fogel, Chicago, 14. März 2004

Einleitung

Es ist wichtig, das Perfekte nicht zum Feind des Guten werden zu lassen, selbst wenn Sie sicher sind, was perfekt ist. Und erst recht, wenn Sie es nicht sind. So unschön es ist, in vergangenen Fehlern gefangen zu sein, machen Sie auch keinen Fortschritt, wenn Sie während des Designs Angst vor Ihrem eigenen Schatten haben.

—Greg Hudson, Subversion-Entwickler

In der Welt der Open Source-Software war das Concurrent Versions System (CVS) das Werkzeug der Wahl für die Versionskontrolle. Und das mit Recht. CVS war selbst eine freie Software. Sein nicht-restriktiver Modus Operandi und seine Unterstützung für den Netzwerkbetrieb – die es Dutzenden von verstreut lebenden Programmierern erlaubte, gemeinsam zu arbeiten – entsprachen ziemlich genau der Natur der Open Source-Welt, in der Zusammenarbeit großgeschrieben wird. CVS und sein halbchaotisches Entwicklungsmodell sind zu Eckpfeilern der Open Source-Kultur geworden.

Doch CVS hatte auch seine Schwächen, und allein das Beheben dieser Schwächen versprach enorm aufwendig zu werden. Da kam Subversion ins Spiel. Subversion war als Nachfolger zu CVS gedacht, und die Entwickler wollten auf zwei Wegen die Herzen der CVS-Benutzer gewinnen: indem sie ein Open Source-System gestalteten, dessen Aufbau (und »Look and Feel«) dem von CVS ähnelt, und indem sie versuchten, die offensichtlichsten Mängel von CVS zu beheben. Das Ergebnis ist zwar nicht unbedingt die nächste große Entwicklung im Versionskontrolldesign, Subversion ist aber in der Tat sehr leistungsfähig, sehr gut benutzbar und sehr flexibel. Und so gut wie alle heutzutage neu gestarteten Open Source-Projekte entscheiden sich für Subversion statt für CVS.

Dieses Buch soll die Version 1.5 des Versionskontrollsystems Subversion dokumentieren. Wir haben versucht, in unserer Behandlung des Themas so gründlich wie möglich zu sein. Allerdings ist die Entwicklergemeinschaft von Subversion sehr eifrig und energisch. Es gibt daher bereits eine ganze Reihe von Funktionen und Verbesserungen, die für künftige Versionen vorgesehen sind und Auswirkungen auf einige der Befehle und besonderen Anmerkungen in diesem Buch haben könnten.

Was ist Subversion?

Subversion ist ein freies/Open Source-Versionskontrollsystem. Das heißt, Subversion verwaltet Dateien und Verzeichnisse sowie die Änderungen, die daran im Laufe der Zeit gemacht werden. Das erlaubt Ihnen, ältere Versionen der Daten wiederherzustellen oder zu untersuchen, in welcher Weise Sie Ihre Daten im Laufe der Zeit geändert haben. Insofern stellen sich viele Leute ein Versionskontrollsystem als eine Art Zeitmaschine vor.

Subversion kann über Netzwerkgrenzen hinweg auf sein Repository zugreifen, wodurch die Nutzung durch Personen auf unterschiedlichen Computern möglich ist. Zu einem gewissen Grad wird die Zusammenarbeit gefördert durch die Möglichkeit, dass unterschiedliche Leute die gleichen Daten von ihren verschiedenen Standorten aus ändern und verwalten können. Schnellere Fortschritte sind möglich, wenn es nicht nur einen einzigen Kanal gibt, den alle Änderungen passieren müssen. Und da die Arbeit versioniert ist, müssen Sie nicht befürchten, dass durch das Einsparen dieses Kanals die Qualität auf der Strecke bleibt – wenn eine Änderung an den Daten verkehrt ist, dann machen Sie diese Änderung einfach rückgängig.

Manche Versionskontrollsysteme sind gleichzeitig Systeme zur Softwarekonfigurationsverwaltung (Software Configuration Management, SCM). Diese Systeme sind speziell darauf ausgerichtet, Quellcodebäume zu verwalten, und besitzen viele Funktionen, die eigens für die Softwareentwicklung angelegt wurden – sie verstehen von sich aus Programmiersprachen oder bringen Werkzeuge zum Kompilieren von Software mit. Subversion gehört allerdings nicht zu diesen Systemen. Es handelt sich vielmehr um ein allgemeines System, das eingesetzt werden kann, um jede Sammlung von Dateien zu verwalten. Bei Ihnen sind diese Dateien vielleicht Quellcode – bei anderen geht es eher um Einkaufslisten, Videoproduktionen oder anderes.

Ist Subversion das richtige Tool?

Wenn Sie ein Anwender oder Systemverwalter sind und überlegen, Subversion einzusetzen, sollten Sie sich als Erstes fragen: »Ist das das richtige Tool für die Aufgabe?« Subversion ist ein fantastischer Hammer, aber Sie sollten darauf achten, nicht jedes Problem als Nagel zu betrachten.

Wenn Sie alte Versionen von Dateien und Verzeichnissen archivieren müssen, sie eventuell wieder zurückholen wollen oder untersuchen möchten, wie sie sich mit der Zeit geändert haben, ist Subversion genau das richtige Tool für Sie. Wenn Sie gemeinsam mit anderen Personen an Dokumenten arbeiten müssen (normalerweise über ein Netzwerk) und dabei verfolgen wollen, wer welche Änderungen vorgenommen hat, ist Subversion auch geeignet. Das ist der Grund dafür, dass Subversion so häufig in der Softwareentwicklung genutzt wird – die Arbeit in einem Entwicklungsteam ist eine soziale Aktivität, und Subversion erleichtert das Zusammenarbeiten mit anderen Programmierern. Natürlich gibt es auch einen Preis für die Verwendung von Subversion: administrativen Aufwand. Sie müssen ein Datenrepository verwalten, in dem die Informationen und ihre »Vergangenheit« abgelegt werden, und Sie müssen daran denken, Sicherungskopien davon zu erstellen. Wenn Sie täglich mit den Daten arbeiten, können Sie die Dateien nicht einfach wie bisher kopieren, verschieben, umbenennen oder löschen. Stattdessen müssen Sie all diese Schritte über Subversion erledigen.

Wenn Sie sich mit diesen zusätzlichen Arbeitsschritten anfreunden können, sollten Sie trotzdem sicherstellen, dass Sie mit Subversion kein Problem lösen, mit dem andere Tools besser umgehen können. Da Subversion zum Beispiel Daten an alle beteiligten Mitarbeiter repliziert, wird es gern als generisches Distributionssystem missbraucht. Manchmal wird Subversion verwendet, um große Mengen von Fotos oder digitaler Musik oder Softwarepakete zu verteilen. Das Problem dabei ist, dass sich solche Daten normalerweise überhaupt nicht ändern. Die Menge von Daten wächst mit der Zeit, aber die einzelnen Dateien innerhalb der Sammlung ändern sich nicht. In diesem Fall ist die Verwendung von Subversion »overkill«.[1] Es gibt einfachere Tools, die Daten effizient replizieren können, und zwar ohne den Overhead der Änderungsverfolgung, wie zum Beispiel rsync oder unison.

Die Geschichte von Subversion

Anfang des Jahres 2000 begann das Unternehmen CollabNet, Inc. (http://www.collab.net) damit, Entwickler zu suchen, die einen Ersatz für CVS schreiben sollten. CollabNet bietet eine Collaboration Software Suite namens CollabNet Enterprise Edition (CEE) an, die als eine Komponente eine Versionskontrolle enthält. CEE benutzte zwar anfangs CVS als sein Versionskontrollsystem, die Grenzen von CVS waren jedoch von Beginn an offensichtlich, und bei CollabNet wusste man, dass man schließlich etwas Besseres finden müsste. Leider hatte sich CVS zu einem Quasistandard in der Open Source-Welt entwickelt, weil es nichts Besseres gab, zumindest nicht unter einer freien Lizenz. Deshalb beschloss man bei CollabNet, ein von Grund auf neues Versionskontrollsystem zu schreiben, das sich zwar an den grundlegenden Ideen von CVS orientiert, allerdings ohne die Fehler und Seltsamkeiten.

Im Februar 2000 kontaktierte das Unternehmen Karl Fogel, den Autor des Buches Open Source Development with CVS (Coriolis 1999), und fragte ihn, ob er an diesem neuen Projekt mitarbeiten wolle. Zufälligerweise diskutierte Karl zu dieser Zeit gerade das Konzept für ein neues Versionskontrollsystem mit seinem Freund Jim Blandy. 1995 hatten die beiden Cyclic Software gegründet, eine Firma, die CVS-Dienstleistungsverträge anbot. Und obwohl sie später das Unternehmen verkauften, benutzten sie weiterhin CVS bei ihrer täglichen Arbeit. Ihr Frust im Umgang mit CVS hatte Jim dazu veranlasst, über bessere Möglichkeiten der Verwaltung versionierter Daten nachzudenken. Er hatte sich dabei nicht nur bereits den Namen »Subversion« ausgedacht, sondern konnte auch schon das grundlegende Design des Subversion-Repository vorweisen. Als CollabNet anrief, stimmte Karl sofort zu, an dem Projekt mitzuarbeiten, und Jim brachte seinen Arbeitgeber, RedHat Software, dazu, ihn auf unbestimmte Zeit für das Projekt freizustellen. CollabNet stellte Karl und Ben Collins-Sussman ein, und die eigentliche Entwurfsarbeit begann im Mai 2000. Mithilfe einiger gut platzierter Hinweise von Brian Behlendorf und Jason Robbins von CollabNet und Greg Stein (zu diesem Zeitpunkt unabhängiger Entwickler, aktiv im WebDAV/DeltaV-Spezifikationsprozess) lockte Subversion schnell eine Gemeinschaft aktiver Entwickler an. Es stellte sich heraus, dass viele Leute die gleichen frustrierenden Erfahrungen mit CVS gemacht hatten und die Chance nutzen wollten, endlich etwas daran zu ändern.

Das ursprüngliche Entwurfsteam einigte sich auf einfache Ziele. Man wollte keine neuen Wege in der Versionskontrollmethodik beschreiten, sondern einfach nur CVS verbessern. Das Team war sich darin einig, dass Subversion dem CVS-Funktionsumfang entsprechen und das gleiche Entwicklungsmodell wahren, nicht jedoch die offensichtlichsten Fehler von CVS kopieren sollte. Zwar musste es kein Eins-zu-eins-Ersatz für CVS sein, sollte aber CVS dennoch so weit gleichen, dass ein Umstieg für jeden CVS-Benutzer mit minimalem Aufwand möglich war.

Nach 14 Monaten Programmierung wurde Subversion am 31. August 2001 eigenständig, das heißt, die Subversion-Entwickler stiegen bei der Verwaltung des Quellcodes von CVS auf Subversion um.

Obwohl CollabNet das Projekt ins Leben gerufen hat und auch weiterhin einen großen Teil der Arbeit finanziert (das Unternehmen bezahlt einige der Vollzeitentwickler von Subversion), wird Subversion wie die meisten Open Source-Projekte betrieben, gesteuert durch eine lockere, transparente Menge von Regeln, die die Meritokratie fördern. Die Copyrightlizenz von CollabNet geht vollständig mit den Debian Free Software Guidelines konform. Mit anderen Worten: Es steht jedem frei, Subversion nach Belieben herunterzuladen, zu verändern und weiterzugeben; man benötigt keine Erlaubnis von CollabNet oder sonst wem.

Die Architektur von Subversion

Abbildung 1 zeigt eine Art Gesamtansicht des Subversion-Designs.

Abbildung 1 Die Architektur von Subversion

Auf der einen Seite befindet sich ein Subversion-Repository, das alle Ihre versionierten Daten aufnimmt. Auf der anderen Seite liegt Ihr Subversion-Clientprogramm, das die lokalen Wiedergaben von Teilen dieser versionierten Daten verwaltet (sogenannte Arbeitskopien). Zwischen diesen Extremen gibt es mehrere Wege durch verschiedene Repository Access-(RA-)Ebenen. Einige dieser Wege verlaufen durch Computernetzwerke und Netzwerkserver, die dann auf das Repository zugreifen. Andere umgehen das Netzwerk ganz und gar und greifen direkt auf das Repository zu.

Die Komponenten von Subversion

Subversion enthält nach der Installation eine Anzahl unterschiedlicher Teile. Im Folgenden bekommen Sie einen Überblick darüber, was Sie erwartet. Wundern Sie sich nicht, wenn Sie nach diesen kurzen Beschreibungen nicht viel schlauer sind als vorher – dieses Buch hat noch viele Seiten, die Licht ins Dunkel bringen werden.

svn

Das Kommandozeilen-Clientprogramm

svnversion

Ein Programm zum Anzeigen des Zustands (im Sinne einer Überprüfung der vorhandenen Objekte) einer Arbeitskopie

svnlook

Ein Werkzeug zum Untersuchen eines Subversion-Repository

svnadmin

Ein Werkzeug zum Erzeugen, Optimieren oder Reparieren eines Subversion-Repository

mod_dav_svn

Ein Plugin-Modul für den Apache-HTTP-Server, das eingesetzt wird, um Ihr Repository über ein Netzwerk erreichbar zu machen

svnserve

Ein eigenes autonomes Serverprogramm, das entweder als Daemon-Prozess laufen oder über SSH aufgerufen werden kann; eine andere Möglichkeit, Ihr Repository anderen über ein Netzwerk zur Verfügung zu stellen.

svndumpfilter

Ein Programm zum Filtern der Subversion-Repository-Streams im Dumpfile-Format

svnsync

Ein Programm zum inkrementellen Spiegeln eines Repository in ein anderes über ein Netzwerk

Was ist neu in Subversion?

Die erste (englischsprachige) Ausgabe dieses Buches wurde 2004 veröffentlicht, kurz nachdem Subversion die Version 1.0 erreicht hatte. In den folgenden vier Jahren gab es von Subversion fünf größere neue Versionen, die Fehler behoben und wichtige neue Features lieferten. Während wir die Onlineversion dieses Buches aktuell halten konnten, freuen wir uns sehr, dass die dritte Auflage von O’Reilly Subversion jetzt bis zum Release 1.5 behandelt, das ein wichtiger Meilenstein für das Projekt ist. Es folgt eine kurze Zusammenfassung der wichtigsten Änderungen seit Subversion 1.0. Beachten Sie, dass es sich dabei nicht um eine vollständige Liste handelt – alle Details erhalten Sie auf der Website von Subversion unter http://subversion.tigris.org/.

Subversion 1.1 (September 2004)

Mit dem Release 1.1 kam FSFS dazu, eine Repository-Storage-Option in einfachen Dateien. Das Berkeley-DB-Backend ist zwar weiterhin weit verbreitet und wird auch weiter unterstützt, aber FSFS wurde die Standardeinstellung für neu erzeugte Repositories, da die Einstiegshürden niedriger sind und der Wartungsaufwand geringer ist. Zudem enthielt dieses Release die Möglichkeit, symbolische Links in der Versionskontrolle mitzuberücksichtigen, URLs automatisch zu escapen und die Benutzerschnittstelle lokalisiert zu verwenden.

Subversion 1.2 (Mai 2005)

Release 1.2 ergänzte die Möglichkeit, serverseitige Sperren für Dateien anzulegen, um damit Commit-Zugriffe auf bestimmte Ressourcen zu serialisieren. Obwohl Subversion immer noch prinzipiell ein Versionskontrollsystem mit parallelem Zugriff ist, können bestimmte Arten binärer Dateien (zum Beispiel Grafiken) nicht zusammengeführt werden. Mit dem Sperrmechanismus lassen sich auch solche Ressourcen versionieren und schützen. Im Zusammenhang damit steht auch eine vollständige WebDAV-Autoversionierungsimplementierung, wodurch Subversion-Repositories als Netzwerkordner eingebunden werden können. Schließlich wird seit Subversion 1.2 ein neuer, schneller Algorithmus zum binären Differenzieren eingesetzt, um ältere Dateiversionen zu komprimieren und zurückzuholen.

Subversion 1.3 (Dezember 2005)

Mit dem Release 1.3 wurden pfadbasierte Autorisierungskontrollen für den Server svnserve möglich, etwas, das bis dahin nur der Apache-Server geboten hatte. Dieser erhielt dazu noch ein paar neue Protokollierungsfeatures. Zudem ging es mit den API-Bindungen von Subversion an andere Sprachen einen großen Schritt weiter.

Subversion 1.4 (September 2006)

Release 1.4 brachte ein komplett neues Tool ins Spiel, svnsync, um eine in eine Richtung funktionierende Repository-Replikation über ein Netzwerk vorzunehmen. Große Teile der Arbeitskopiemetadaten wurden so umgeschrieben, dass sie nicht mehr XML verwendeten (und damit die Geschwindigkeit des Clients stieg), während das Berkeley-DB-Repository-Backend die Fähigkeit erhielt, sich nach einem Servercrash automatisch wiederherzustellen.

Subversion 1.5 (Juni 2008)

Auf das Release 1.5 musste man länger warten als auf die vorigen Releases, aber das wichtigste enthaltene Feature war gigantisch: semiautomatisches Verfolgen beim Verzweigen und Zusammenführen. Das war ein großer Gewinn für die Anwender und führte Subversion in Bereiche, die mit CVS nie betreten werden konnten – Subversion ist nun kommerziellen Konkurrenten wie Perforce und ClearCase ebenbürtig. Subversion 1.5 führte zudem eine ganze Reihe weiterer benutzerzentrierter Features ein, wie zum Beispiel die interaktive Auflösung von Dateikonflikten, partielles Auschecken, clientseitige Verwaltung von Änderungslisten, eine mächtige neue Syntax für externe Definitionen und Unterstützung der Authentifizierung via Simple Authentication and Security Layer (SASL) für den Server svnserve.

Die Zielgruppe

Dieses Buch ist für Leute gedacht, die sich mit Computern auskennen und Subversion einsetzen wollen, um ihre Daten zu verwalten. Subversion läuft zwar unter einer ganzen Reihe von Betriebssystemen, seine wichtigste Benutzerschnittstelle jedoch ist kommandozeilenbasiert. Dieses Kommandozeilenwerkzeug (svn) und einige weitere Hilfsprogramme werden im vorliegenden Buch besprochen und verwendet.

Aus Gründen der Konsistenz gehen die Beispiele in diesem Buch davon aus, dass der Leser ein Unix-artiges Betriebssystem benutzt und relativ vertraut mit Unix und Kommandozeilenschnittstellen ist. Nichtsdestoweniger läuft das Programm svn auch auf Nicht-Unix-Plattformen wie Microsoft Windows. Mit wenigen Ausnahmen, wie etwa der Benutzung von Rückstrichen (\) anstelle von Schrägstrichen (/) als Pfadtrenner, sind die Eingaben und Ausgaben dieses Werkzeugs beim Betrieb unter Windows identisch mit denen auf seinem Unix-Gegenstück.

Wir nehmen an, dass unsere Leser Programmierer oder Systemadministratoren sind, die Änderungen an Quellcodes im Auge behalten müssen. Dies ist die gebräuchlichste Anwendung für Subversion und bildet daher das Szenario, das allen Beispielen in diesem Buch zugrunde liegt. Mit Subversion kann man aber auch alle anderen Arten von Informationen verwalten – Bilder, Musik, Datenbanken, Dokumentationen usw. Für Subversion sind Daten einfach Daten.

Dieses Buch wurde zwar unter der Annahme geschrieben, dass der Leser noch nie ein Versionskontrollsystem benutzt hat, wir haben aber auch versucht, Anwendern von CVS (und anderen Systemen) den Umstieg auf Subversion zu erleichtern. Im Text dafür vorgesehene Kästen gehen gelegentlich auf andere Versionskontrollsysteme ein, und Anhang B fasst viele der Unterschiede zwischen CVS und Subversion zusammen.

Beachten Sie auch, dass viele der in diesem Buch verwendeten Quellcodebeispiele wirklich nur Beispiele sind. Auch wenn sie sich mit den richtigen Compilereinstellungen übersetzen lassen, sind sie nur dazu gedacht, für ein bestimmtes Szenario zu stehen. Sie sind keine Beispiele für gute Programmierpraxis oder einen guten Programmierstil.

Wie Sie dieses Buch lesen sollten

Autoren technischer Bücher sehen sich immer einem gewissen Dilemma gegenüber: Sollen sie sich an die Leser richten, die Top-down lernen, oder an die, die Bottom-up vorgehen? Ein Top-down-Lernender zieht es vor, die Dokumentation zu überfliegen und einen groben Überblick zu erhalten, wie das System funktioniert. Erst danach beginnt er, mit der Software zu arbeiten. Ein Bottom-up-Lernender verfährt eher nach dem »Learning by Doing«-Prinzip – er steigt in die Software ein und versucht herauszufinden, wie etwas funktioniert. Auf Abschnitte im Buch greift er nur zurück, wenn es notwendig ist. Die meisten Bücher werden nur für einen von beiden Typen geschrieben, und dieses Buch ist zweifelsohne am Top-down-Ansatz ausgerichtet. (Und wenn Sie diesen Abschnitt tatsächlich lesen, sind Sie vermutlich selbst ein Top-down-Lernender!) Aber auch als Bottom-up-Person müssen Sie nicht verzweifeln. Dieses Buch ist zwar als umfassender Überblick über die verschiedenen Bereiche von Subversion gedacht, die einzelnen Abschnitte enthalten aber viele Beispiele, die Sie ausprobieren können. Wenn Sie sehr ungeduldig sind und einfach loslegen wollen, können Sie direkt Anhang A ansteuern.

Unabhängig von Ihrem individuellen Lernverhalten hat sich dieses Buch zum Ziel gesetzt, Leute mit unterschiedlichem Hintergrundwissen anzusprechen – von denjenigen, die sich überhaupt nicht mit der Versionskontrolle auskennen bis hin zu erfahrenen Systemadministratoren. Je nach Ihrem eigenen Hintergrund werden bestimmte Kapitel für Sie mehr oder weniger wichtig sein. Im Folgenden finden Sie Empfehlungen für die verschiedenen Lesertypen:

Erfahrene Systemadministratoren

Die Annahme ist, dass Sie wahrscheinlich bereits früher Versionskontrollsysteme benutzt haben und darauf brennen, so schnell wie möglich einen Subversion-Server an den Start zu bringen. Kapitel 5, und Kapitel 6, zeigen Ihnen, wie Sie Ihr erstes Repository anlegen und es über das Netzwerk verfügbar machen. Danach bilden Kapitel 2, und Anhang D, die schnellsten Wege, um den Subversion-Client kennenzulernen.

Neue Anwender

Ihr Administrator hat Subversion vermutlich bereits eingerichtet, und Sie müssen nun lernen, mit dem Client umzugehen. Falls Sie noch nie ein Versionskontrollsystem benutzt haben, ist Kapitel 1, eine unbedingt notwendige Einführung in die Konzepte, die hinter der Versionskontrolle stecken. Kapitel 2, bietet dann eine Tour durch den Subversion-Client.

Fortgeschrittene Benutzer

Unabhängig davon, ob Sie Benutzer oder Administrator sind, irgendwann wird Ihr Projekt größer. Sie wollen wissen, wie Sie ausgefallenere Dinge mit Subversion erledigen können, z.B. wie Sie die Unterstützung von Subversion für Eigenschaften einsetzen können (Kapitel 3), Zweige benutzen und Zusammenführungen ausführen (Kapitel 4), wie Sie Laufzeitoptionen konfigurieren (Kapitel 7) und anderes. Diese Kapitel sind zunächst nicht so wichtig, lesen Sie sie aber auf jeden Fall, wenn Sie sich mit den Grundlagen vertraut gemacht haben.

Entwickler

Vermutlich sind Sie bereits mit Subversion vertraut und wollen es nun entweder erweitern oder auf der Grundlage seiner vielen APIs neue Software entwickeln. Kapitel 8, ist genau richtig für Sie.

Das Buch endet mit Referenzmaterial – Kapitel 9, enthält eine Referenz für alle Subversion-Befehle – und die Anhänge behandeln eine Reihe von nützlichen Themen. Auf diese Kapitel werden Sie wahrscheinlich zurückkommen, nachdem Sie dieses Buch beendet haben.

Konventionen in diesem Buch

Die folgenden Konventionen werden in diesem Buch benutzt.

Kapitälchen

werden für Menü-Überschriften und -Buttons verwendet.

Nichtproportionalschrift

wird für Befehle, Befehlsausgaben und Schalter benutzt.

Nichtproportionalschrift kursiv

wird für benutzbare Objekte in Code und Text benutzt.

Kursivschrift

wird für die Namen von Programmen und Unterbefehlen von Subversion-Tools, Datei- und Verzeichnisnamen sowie neue Begriffe eingesetzt.

Wir haben zudem besonders hilfreiche oder wichtige Informationen über das Buch verteilt (an den im Kontext passenden Stellen) und mit Symbolen versehen, damit Sie sie leichter finden. Die folgenden Symbole werden dabei verwendet:

Symbole

Tipp

Dieses Symbol weist auf einen hilfreichen Hinweis oder empfohlene Best Practices hin.

Warnung

Dieses Symbol kennzeichnet eine Warnung. Achten Sie besonders darauf, um vermeidbare Probleme zu umgehen.

Der Aufbau dieses Buches

Im Folgenden finden Sie eine Übersicht über die verschiedenen Kapitel und ihren Inhalt.

Kapitel 1

Erläutert die Grundlagen der Versionskontrolle und die verschiedenen Versionierungsmodelle sowie das Repository von Subversion, Arbeitskopien und Revisionen.

Kapitel 2

Führt Sie durch einen Tag im Leben eines Subversion-Benutzers. Dieses Kapitel demonstriert, wie Sie einen Subversion-Client einsetzen, um Daten zu beziehen, zu modifizieren und zu bestätigen.

Kapitel 3

Behandelt komplexere Features, mit denen normale Anwender eventuell einmal in Kontakt kommen werden, wie zum Beispiel versionierte Metadaten, Datei-Locking und Peg-Revisionen.

Kapitel 4

Erläutert Zweige, Zusammenführungen und Tagging, einschließlich der besten Vorgehensweisen für das Verzweigen und Zusammenführen, gebräuchlicher Anwendungsfälle und Beschreibungen, wie sich Änderungen rückgängig machen lassen und wie leicht Sie von einem Zweig zu einem anderen wechseln können.

Kapitel 5

Beschreibt die Grundlagen des Subversion-Repository und die Art und Weise, wie Sie ein Repository erzeugen, konfigurieren und warten, sowie die Werkzeuge, um all dies zu erledigen.

Kapitel 6

Erklärt, wie Sie Ihren Subversion-Server konfigurieren können, sowie verschiedene Möglichkeiten, auf Ihr Repository zuzugreifen: HTTP, das svn-Protokoll und den lokalen Festplattenzugriff. Es behandelt außerdem die Einzelheiten der Authentifizierung, der Autorisierung und des anonymen Zugriffs.

Kapitel 7

Erkundet die Konfigurationsdateien des Subversion-Client und die Handhabung internationalisierter Texte und zeigt, wie man externe Tools zur Zusammenarbeit mit Subversion bringt.

Kapitel 8

Beschreibt die Interna von Subversion, das Subversion-Dateisystem und die administrativen Bereiche der Arbeitskopie aus Sicht eines Programmierers. Demonstriert, wie Sie die öffentlichen APIs benutzen können, um ein Programm zu schreiben, das Subversion verwendet.

Kapitel 9

Erläutert ausführlich alle Unterbefehle von svn, svnadmin und svnlook mit vielen Beispielen für alle Gelegenheiten!

Anhang A

Eine Blitzerläuterung für Ungeduldige, wie man Subversion installiert und es direkt nutzt. Wir haben Sie gewarnt!

Anhang B

Behandelt die Ähnlichkeiten und Unterschiede zwischen Subversion und CVS mit zahlreichen Vorschlägen dahingehend, wie Sie all die schlechten Gewohnheiten aufgeben können, die Sie in den langen Jahren der Benutzung von CVS angenommen haben. Sie finden hier Informationen über Subversion-Revisionsnummern, versionierte Verzeichnisse, Offline-Operationen, den Vergleich von update und status, Zweige, Tags, Metadaten, Konfliktauflösung und Authentifizierung.

Anhang C

Beschreibt die Einzelheiten von WebDAV und DeltaV und wie Sie Ihr Subversion-Repository so konfigurieren können, dass es lesend und schreibend als DAV-Freigabe gemountet wird.

Anhang D

Enthält die deutsche Adaption des vollständigen juristischen Textes der Creative Commons-Lizenz, unter der die englischsprachige Ausgabes des Buches steht.

Dieses Buch ist frei

Dieses Buch war ursprünglich eine Sammlung von Dokumentationen, die von den Entwicklern des Subversion-Projekts geschrieben und dann zu einem Werk zusammengefasst und umgeschrieben wurden. Als solches unterlag es immer einer freien Open Source-Lizenz (siehe Anhang D). Um genau zu sein, wurde das Buch unter den Augen der Öffentlichkeit geschrieben, als Teil des Subversion-Projekts selbst. Das bedeutet zweierlei:

Sie werden immer die neueste englischsprachige Version dieses Buches in seinem eigenen Subversion-Repository finden.

Sie können an diesem Buch nach Belieben Änderungen vornehmen und es verteilen – es unterliegt einer freien Lizenz. Sie müssen nur immer auf die ursprünglichen Autoren hinweisen. Anstatt Ihre eigene private Version dieses Buches zu verteilen, hätten wir es natürlich lieber, wenn Sie Rückmeldungen und Verbesserungen an die Subversion-Entwicklergemeinschaft schicken würden.

Die Onlineheimat des Buches und einen Großteil der Übersetzungen von freiwilligen Mitarbeitern finden Sie unter http://svnbook.red-bean.com. Hier erhalten Sie Verweise auf die neuesten Releases und getaggten Versionen des Buches in verschiedenen Formaten, aber auch Erläuterungen darüber, wie Sie auf das Subversion-Repository des Buches zugreifen können (in dem die DocBook-XML-Quelldateien zu Hause sind). Rückmeldungen sind willkommen, genau wie Ermutigungen. Schicken Sie Kommentare, Kritik und Korrekturen an den Quelldateien des Buches an svnbook-dev@red-bean.com.

Danksagungen

Dieses Buch wäre ohne Subversion nicht möglich (und auch nicht sehr nützlich). Daher möchten die Autoren Brian Behlendorf und CollabNet für die Vision danken, ein solch riskantes und ambitioniertes neues Open Source-Projekt zu unterstützen, Jim Blandy für den ursprünglichen Subversion-Namen und -Entwurf – Wir lieben dich, Jim! – und Karl Fogel[2] dafür, dass er ein solch guter Freund und großartiger Leiter der Gemeinschaft ist – in dieser Reihenfolge.

Dank auch an O’Reilly und unsere Lektoren Chuck Toporek, Linda Mui, Tatiana Apandi, Mary Brady und Mary Tresler. Ihre Geduld und Unterstützung waren unendlich groß.

Schließlich danken wir den zahllosen Menschen, die mit zwanglosen Rezensionen, Vorschlägen und Fehlerberichten dieses Buchprojekt unterstützt haben. Dies ist zwar jetzt ohne Zweifel keine vollständige Liste, aber dieses Buch wäre unvollständig und fehlerhaft, wenn nicht folgende Leute daran mitgeholfen hätten: Bhuvaneswaran A, David Alber, C. Scott Ananian, David Anderson, Ariel Arjona, Seth Arnold, Jani Averbach, Charles Bailey, Ryan Barrett, Francois Beausoleil, Brian R. Becker, Yves Bergeron, Karl Berry, Jennifer Bevan, Matt Blais, Jim Blandy, Phil Bordelon, Sietse Brouwer, Tom Brown, Zack Brown, Martin Buchholz, Paul Burba, Sean Callan-Hinsvark, Branko Cibej, Archie Cobbs, Jason Cohen, Ryan Cresawn, John R. Daily, Peter Davis, Olivier Davy, Robert P. J. Day, Mo DeJong, Brian Denny, Joe Drew, Markus Dreyer, Nick Duffek, Boris Dusek, Ben Elliston, Justin Erenkrantz, Jens M. Felderhoff, Kyle Ferrio, Shlomi Fish, Julian Foad, Chris Foote, Martin Furter, Vlad Georgescu, Peter Gervai, Dave Gilbert, Eric Gillespie, David Glasser, Marcel Gosselin, Lieven Govaerts, Steve Greenland, Matthew Gregan, Tom Gregory, Maverick Grey, Art Haas, Mark E. Hamilton, Eric Hanchrow, Liam Healy, Malte Helmert, Michael Henderson, Øyvind A. Holm, Greg Hudson, Alexis Huxley, Auke Jilderda, Toby Johnson, Jens B. Jorgensen, Tez Kamihira, David Kimdon, Mark Benedetto King, Robert Kleemann, Erik Kline, Josh Knowles, Andreas J. Koenig, Axel Kollmorgen, Nuutti Kotivuori, Kalin Kozhuharov, Matt Kraai, Regis Kuckaertz, Stefan Kueng, Steve Kunkee, Scott Lamb, Wesley J. Landaker, Benjamin Landsteiner, Vincent Lefevre, Morten Ludvigsen, Dennis Lundberg, Paul Lussier, Bruce A. Mah, Jonathon Mah, Karl Heinz Marbaise, Philip Martin, Feliciano Matias, Neil Mayhew, Patrick Mayweg, Gareth McCaughan, Craig McElroy, Simon McKenna, Christophe Meresse, Jonathan Metillon, Jean-Francois Michaud, Jon Middleton, Robert Moerland, Marcel Molina Jr., Tim Moloney, Alexander Mueller, Tabish Mustufa, Christopher Ness, Roman Neuhauser, Mats Nilsson, Greg Noel, Joe Orton, Eric Paire, Dimitri Papadopoulos-Orfanos, Jerry Peek, Chris Pepper, Amy Lyn Pilato, Kevin Pilch-Bisson, Hans Polak, Dmitriy Popkov, Michael Price, Mark Proctor, Steffen Prohaska, Daniel Rall, Srinivasa Ramanujan, Jack Repenning, Tobias Ringstrom, Jason Robbins, Garrett Rooney, Joel Rosdahl, Christian Sauer, Ryan Schmidt, Jochem Schulenklopper, Jens Seidel, Daniel Shahaf, Larry Shatzer, Danil Shopyrin, Erik Sjoelund, Joey Smith, W. Snyder, Stefan Sperling, Robert Spier, M. S. Sriram, Russell Steicke, David Steinbrunner, Sander Striker, David Summers, Johan Sundstroem, Ed Swierk, John Szakmeister, Arfrever Frehtes Taifersar Arahesis, Robert Tasarz, Michael W. Thelen, Mason Thomas, Erik van der Kolk, Joshua Varner, Eric Wadsworth, Chris Wagner, Colin Watson, Alex Waugh, Chad Whitacre, Andy Whitcroft, Josef Wolf, Luke Worth, Hyrum Wright, Blair Zajac, Florian Zumbiehl und die gesamte Subversion-Gemeinschaft.

Von Ben Collins-Sussman

Ich danke meiner Frau Frances, die viele Monate lang statt des üblichen »Liebling, ich muss noch ein paar E-Mails schreiben!« ein »Liebling, ich arbeite noch an dem Buch!« zu hören bekam. Ich weiß gar nicht, wo sie all die Geduld hernimmt! Sie ist mein perfektes Gegengewicht.

Ein Dank geht auch an meine große Familie und meine Freunde für ihre aufrichtige Ermutigung, obwohl sie an dem Thema eigentlich nicht interessiert waren. (Sie wissen schon, diejenigen, die sagen: »Ohh, du hast ein Buch geschrieben?«, und bei der Information, dass es sich um ein Computerbuch handelt, sofort abschalten.)

Danke an all meine engen Freunde, die mich sehr, sehr reich machen. Schaut mich nicht so an – Ihr wisst schon.

Danke an meine Eltern für das perfekte »Low-Level-Formatting« und dafür, dass Ihr so unglaubliche Vorbilder seid. Danke an meine Kinder, dass ich die Möglichkeit habe, das weiterzugeben.

Von Brian W. Fitzpatrick

Ein riesiges Dankeschön geht an meine Frau Marie dafür, dass sie so verständnisvoll, hilfsbereit und vor allem geduldig war. Dank an meinen Bruder Eric, der mich damals an die Unix-Programmierung herangeführt hat. Ich danke meiner Mutter und meiner Großmutter für ihre Unterstützung, ganz besonders an den Weihnachtsfeiertagen, an denen ich nach Hause kam und mich sofort hinter meinem Laptop vergrub, um an dem Buch zu arbeiten.

An Mike und Ben: Es war eine Freude, mit Euch an dem Buch zu arbeiten. Jungs, was sage ich, es ist immer eine Freude, mit Euch zu arbeiten!

An alle in der Subversion-Gemeinschaft und der Apache Software Foundation: Danke, dass Ihr mich aufgenommen habt. Es vergeht kein Tag, an dem ich nicht wenigstens von einem von Euch etwas lerne.

Schließlich danke ich meinem Großvater, der mich immer gelehrt hat, dass »Freiheit gleichbedeutend ist mit Verantwortung«. Ich stimme dem voll und ganz zu.

Von C. Michael Pilato

Ein besonderer Dank an Amy, meine Frau und beste Freundin, für ihre Liebe und ihre geduldige Unterstützung, dafür, dass sie lange Nächte in Kauf genommen und sogar die Versionskontrollprozesse ertragen hat, die ich ihr aufgedrückt habe. Keine Angst, Schatz, Du wirst in Nullkommanix ein TortoiseSVN-Wizard sein!

Gavin, Du kannst jetzt die Hälfte der Wörter in diesem Buch selber lesen, aber leider ist es genau die andere Hälfte, die die Schlüsselkonzepte vermittelt. Und sorry, Aidan, ich habe keine Möglichkeit gefunden, Disney/Pixar-Charaktere in den Text einzuarbeiten. Aber Daddy hat Euch beide lieb und kann es nicht erwarten, euch Programmieren beizubringen.

Mom und Dad, danke für Eure stetige Unterstützung und Euren Enthusiasmus. Schwiegermama und Schwiegerpapa, danke für dasselbe und Eure fantastische Tochter.

Hut ab vor Shep Kendall, durch den die Welt der Computer sich das erste Mal für mich geöffnet hat, Ben Collins-Sussman, meinen Reiseführer durch die Open Source-Welt, Karl Fogel – Du bist mein .emacs, Greg Stein für das Beisteuern seines praktischen Programmiererwissens und Brian Fitzpatrick dafür, dass er seine Erfahrungen beim Schreiben mit mir geteilt hat. An die vielen Leute, von denen ich andauernd neue Kenntnisse aufschnappe – macht weiter so!

Schließlich an den Einen, der kreative Exzellenz in Perfektion demonstriert – ich danke Dir.

[1] Oder wie man so schön sagt: »Mit Kanonen auf Spatzen schießen.«

[2] Oh, und danke, Karl, dass du zu überarbeitet warst, um dieses Buch selbst zu schreiben.

Kapitel 1. Grundlegende Konzepte

Dieses Kapitel ist eine kurze, lockere Einführung in Subversion. Falls Sie noch keine Ahnung von Versionskontrolle haben, sollten Sie dieses Kapitel unbedingt lesen. Wir beginnen mit einer Beschreibung der allgemeinen Konzepte der Versionskontrolle, nähern uns dann an die speziellen Ideen hinter Subversion an und zeigen einige einfache Beispiele für Subversion in Aktion.

Auch wenn in den Beispielen dieses Kapitels Sammlungen von Programmquellcode gemeinsam genutzt werden, kann Subversion durchaus alle Arten von Dateisammlungen verwalten – es beschränkt sich nicht darauf, Programmierer zu unterstützen.

Das Repository

Subversion ist ein zentralisiertes System zum gemeinsamen Verwenden von Informationen. Seinen Kern bildet ein Repository, das den zentralen Datenspeicher darstellt. Das Repository speichert Informationen in Form eines Dateisystembaums – eine typische Hierarchie von Dateien und Verzeichnissen. Eine beliebige Anzahl von Clients stellt eine Verbindung mit dem Repository her und liest oder schreibt dann diese Dateien. Durch das Schreiben der Daten stellt ein Client die Informationen anderen zur Verfügung; durch das Lesen der Daten empfängt der Client Informationen von anderen. Abbildung 1.1 illustriert das.

Weshalb ist das interessant? Bisher klingt es wie die Definition eines typischen Fileservers. Und das Repository ist in der Tat eine Art Fileserver, allerdings keiner von der üblichen Sorte. Das Besondere an einem Subversion-Repository besteht darin, dass es sich jede Änderung merkt, die jemals in ihm festgehalten wurde: alle Änderungen an allen Dateien, und sogar Änderungen am Verzeichnisbaum selbst, wie etwa Ergänzungen, Löschungen und die Neuanordnung von Dateien und Verzeichnissen.

Wenn ein Client Daten aus dem Repository liest, sieht er normalerweise nur die neueste Version des Dateisystembaums. Der Client besitzt aber auch die Fähigkeit, frühere Zustände des Dateisystems anzuschauen. Beispielsweise kann ein Client Fragen zur History stellen, etwa »Was enthielt dieses Verzeichnis am letzten Mittwoch?« oder »Welche Person hat zuletzt Änderungen an dieser Datei vorgenommen, und welche Änderungen waren das?«. Solche Fragen bilden das Herzstück jedes Versionskontrollsystems: Es sind Systeme, die dafür vorgesehen sind, Änderungen an Daten über einen Zeitraum hinweg zu verfolgen.

Abbildung 1.1 Ein typisches Client/Server-System

Versionierungsmodelle

Die Hauptaufgabe eines Versionskontrollsystems besteht darin, das gemeinschaftliche Bearbeiten und Benutzen von Daten zu ermöglichen. Allerdings verwenden unterschiedliche Systeme auch unterschiedliche Strategien, um dieses Ziel zu erreichen. Es ist aus verschiedenen Gründen wichtig, diese unterschiedlichen Strategien zu verstehen. Erst einmal hilft Ihnen das dabei, verschiedene Versionskontrollsysteme einander gegenüberzustellen und zu vergleichen, falls Sie neben Subversion andere Systeme kennenlernen. Zudem können Sie mit diesem Wissen Subversion effektiver nutzen, da Subversion selbst mehrere Vorgehensweisen unterstützt.

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!