SVN für CVS-Benutzer

SVN für CVS-Benutzer If C gives you enough rope to hang yourself, think of Subversion as a sort of rope storage facility. Brian W. Fitzpatrick Inhalt 1. Überblick... 2 1.1. Kommandozeile... 2 1.2. Plattform... 2 1.3. Geschichte... 2 1.4. Mehr Informationen... 2 1.5. Wichtige Unterschiede zwischen Subversion und CVS... 2 1.6. Konzepte... 5 2. Tägliche Arbeit... 6 2.1. Das svn-kommando... 6 2.2. Checkout, update, checkin, revert... 6 2.3. Import, add, delete, revert... 7 2.4. Weitere interessante Befehle... 8 3. Tags und Branches... 8 3.1. Anlegen von Tags und Branches... 8 3.2. Mergen... 8 4. Administration... 10 4.1. Backups... 10 4.2. svnserve... 11 5. 3rd-Party Tools... 12 6. Ausgewählte Links... 12 Herkunft dieses Textes Dieser Text wurde von Hendrik Schober bei der LuraTech Imaging GmbH für die interne Verwendung erstellt. In Anerkennung der Tatsache, dass CVS, Subversion, das SVN-Buch und alle anderen dazu verwendeten Quellen frei und unentgeltlich benutzbar sind, wurde es mir dankenswerterweise gestattet, ihn zu veröffentlichen. Versionen 1.0 2009-06-03 1. Version 1.1 2009-06-09 Kapitel Administration deutlich erweitert, Kapitel Ausgewählte Links hinzugefügt SVN für CVS-Benutzer.doc 12 Seiten Hendrik Schober, 09.06.2009

Überblick 1. Überblick 1.1. Kommandozeile Subversion ist wie CVS in allererster Linie ein Kommandozeilenprogramm. Es gibt diverse graphische Tools, welche einen auch ohne Kommandozeile sehr gut arbeiten lassen, aber die Funktionsweise von Subversion versteht man m.e. am besten anhand der zugrunde liegenden Kommandozeilen-Syntax. Das bedeutet nicht, dass man diese Syntax auswendig kennen oder später verwenden muss. Aber es ist sinnvoll zu wissen, dass hinter Tagging und Branching dasselbe Kommando (svn copy) steckt, auch wenn die GUIs vieler Tools v.a. Tagging und Branching anbieten, aber nicht das Kopieren an sich. Es ist überhaupt kein Problem, mit diesem Wissen Tools wie TortoiseSVN zu benutzen, umgekehrt wäre es aber u.u. deutlich schwerer. Deshalb orientiert sich dieser Text an der Kommandozeilen-Syntax. 1.2. Plattform Subversion ist von Anfang an plattform-übergreifend konzipiert worden und läuft auf sehr vielen Plattformen. Dieses Dokument ist allerdings v.a. aus der Sicht von Windows-Benutzern geschrieben worden, auch wenn die genannten Fakten und Rezepte im Wesentlichen plattform-übergreifend gültig sein sollten. Wichtige Ausnahmen sind die Kapitel 4.2 (svnserve, S. 11) und 5 (3rd-Party Tools, S. 12). 1.3. Geschichte Die Geschichte von Subversion begann im Jahr 2000, als Karl Fogel, Jim Blandy (von ihm stammt übrigens der Name Subversion) und Ben Collins-Sussman anfingen, eine besseres CVS zu schreiben. Ziel war es nicht, etwas völlig neues zu erfinden, sondern ein Versionsverwaltungs-Tool zu schreiben, dass sich wie CVS verhält, aber die offensichtlichsten Fehler von CVS vermeidet. Es sollte einfach sein, von CVS auf Subversion umzusteigen. In der zweiten Hälfte des Jahres 2001 war Subversion weit genug gediehen, dass die Entwickler nicht mehr CVS benutzen mussten, um ihren Code zu verwalten, sondern zu Subversion wechseln konnten. Die Version 1.0.0 wurde im Februar 2004 veröffentlicht. 1.4. Mehr Informationen Subversion selbst sowie Unmengen an Informationen über Subversion und Tools finden sich auf Subversions Website (s. Link unter 6., S. 12). Eine der wichtigsten (dort genannten) Informationsquellen ist das u.a. auch online lesbare Buch Version Control with Subversion (Link ebenfalls unter 6., S. 12). 1.5. Wichtige Unterschiede zwischen Subversion und CVS 1.5.1. Das Repository Ein Subversion-Repository ist im Prinzip ein versioniertes Dateisystem mit allen Verzeichnissen und Dateien plus zugehörigen Metadaten. Subversion ist in der Lage, interne Kopien dieses Baumes (bzw. von Teilen desselben) anzulegen, wobei immer Hendrik Schober, 09.06.2009 2/12 SVN für CVS-Benutzer.doc

Überblick SVN für CVS-Benutzer lazy copies angelegt werden, wirklich kopiert wird also nur, wenn sich etwas verändert. Diese grundlegende Architektur bestimmt praktisch alle alltäglichen Arbeitsschritte mit Subversion, vom Revisionssystem über Tags und Branches bis hin zu Backup- Lösungen. 1.5.2. Revisionsnummern, Changesets und Logs Anders als bei CVS gelten Revisionsnummern in Subversion für das gesamte Repository, nicht für einzelne Dateien. Jeder Checkin erzeugt eine Kopie des gesamten internen Dateibaumes und dabei neue, Repository-weite Revisionsnummer. Revision 10435 bezeichnet damit einen bestimmten Zustand des gesamten Repositories, nicht einer einzelnen Datei. Das mag anfangs ungewohnt sein, hat aber andererseits auch ganz klare Vorteile. (Natürlich ist es trotzdem weiterhin möglich, einen wilden Mix aus verschiedenen Dateien verschiedener Revisionsstände mit einem Tag zu versehen.) Deutlich wird das in der Terminologie: Wird in CVS von Revision N der Datei X gesprochen, spricht man in Subversion eher von Datei (oder Verzeichnis) X in Revision N. Revision N ist damit eine Kopie, die den Stand des Repositorys nach N Commits bezeichnet. Die Änderungen, die von Revision N-1 zu Revision N führten, werden als Changeset bezeichnet. Dazu gehören Änderungen an Dateien, Ordnern und deren Metadaten, Hinzufügen oder Löschen von Objekten usw. Da ein bestimmtes Changeset immer mit einer bestimmten Revision verbunden ist, werden die Begriffe Changeset und Revision oft synonym verwendet. An Stellen, wo das Changeset gemeint ist, das von Revision N-1 zu Revision N geführt hat, wird stattdessen oft Revision N verwendet. Dies spiegelt sich auch in der Syntax des Kommandozeilenprogramms wider. (Um Informationen über das Changeset zu sehen, das von Revision 4710 zu 4711 geführt hat, kann ich svn log -r 4711 aufrufen, obwohl mittels r eigentlich eine bestimmte Revision angegeben wird.) In Subversion ist ein Commit, egal wie viele Dateien er enthält, atomar. Das heißt, das Einchecken funktioniert entweder ganz oder (falls das Netzwerk Probleme macht, ein Commit-Hook das Einchecken einer Datei verhindert oder ähnliches) gar nicht. Das verhindert das Problem, dass ein Benutzer eine große Anzahl an Dateien einchecken will, das Einchecken aber nach einem Teil der Dateien aus irgendeinem Grund mit einem Fehler abbricht, so dass das Repository dann in einem inkonsistenten Zustand ist. Dass Subversion Commits als atomare Operationen auffasst, die sich über mehrere Dateien erstrecken können, macht auch Logs sehr viel nützlicher als in CVS. Ein Log- Eintrag ist dadurch eine Operation mit einer Log-Message und einer oder eben mehreren Dateien und Ordnern, statt, wie in CVS, eine Änderung an einer Datei (die u.u. mit vielen anderen Änderungen an anderen Dateien korrespondiert). 1.5.3. Umbenennen In Subversion können Dateien umbenannt, verschoben und kopiert werden. Umbenennen und Verschieben sind z.z. zwar unter der Haube per Kopieren und Löschen implementiert, aber auch das stellt sicher, dass umbenannte, kopierte oder verschobene Dateien ihre gesamte History behalten. Subversion speichert nicht nur Dateien, sondern Verzeichnis-Bäume. Dabei behandelt es Verzeichnisse genauso wie Dateien. Das bedeutet, dass Kommandos wie add, SVN für CVS-Benutzer.doc 3/12 Hendrik Schober, 09.06.2009

delete, rename, move usw. genauso auf Verzeichnisse anwendbar sind, wie auf Dateien. Überblick 1.5.4. Properties Alle eingecheckten Dateien und Verzeichnisse haben Metadaten, sogenannte Properties. Das sind Key-Value-Paare mit beliebigen (auch binären) Informationen. Es gibt einige von Subversion vordefinierte Property-Keys mit bestimmten Bedeutungen (wie z.b. svn:eol-style, welches die Übersetzung von Zeilenendezeichen steuert, oder svn:ignore, das die Aufgabe von.cvsignore übernommen hat). Einige Tools, wie z.b. TortoiseSVN, kommen mit ihren eigenen vordefinierten Properties. Es lassen sich aber beliebig viele andere anlegen. Neben den normalen, versionierten Properties gibt es noch nicht versionierte Properties, deren Änderungen nicht mit verfolgt werden. Diese beziehen sich jeweils auf ein Changeset. Sie enthalten u.a. den Autor, das Eincheck-Datum und die Log- Message. 1.5.5. Tags und Branches Tagging und Branching einer Datei oder eines Verzeichnisses ist in Subversion so implementiert, dass eine Kopie einer bestimmten Version eines Teils des internen, versionierten Baumes unter einem beliebigen Verzeichnis angelegt wird. Das hat mehrere Konsequenzen: Zum einen ist, aufgrund des lazy copying (s. 1.5.1, S. 2), das Werfen eines Tags, egal über wie viele Dateien, eine O(1)-Operation, über deren Geschwindigkeit CVS- Benutzer anfangs sehr erstaunt sind. Zum anderen sind Tags und Branches zwar konzeptionell unterschiedlich, werden aber auf die gleiche Art und Weise angelegt: durch Kopieren. Es ist gibt also keine Unterschiede mehr zwischen normalen Tags und Branch-Tags. Die kanonische Struktur eines Subversion -Repository beachtet zwar die konzeptionellen Unterschiede, aber als Benutzer ist man keinesfalls daran gebunden, diese Struktur zu verwenden. Da Tags und Branches nur Verzeichnisse im Repository sind, lassen sich alle Verzeichnis-Operationen (Löschen, Umbenennen, Verschieben) auch sehr einfach auf Tags und Branches anwenden. So kann man z.b. Feature-Branches, die für die Entwicklung eines bestimmten Features angelegt wurden, nach Abschluss dieser Entwicklung wieder löschen. Subversion verfolgt Merge-Operationen zwischen verschiedenen Branches (in speziellen Properties) und sorgt dafür, dass Änderungen aus einem Branch nicht mehrfach in einen anderen gemergt werden. 1.5.6. Textdateien und binäre Dateien In CVS müssen Binärdateien (mit kb) gekennzeichnet werden, damit CVS nicht versucht, Zeilenenden zu übersetzen und Keywords einzuführen. In Subversion ist das nicht nötig, denn Subversion führt diese Änderungen nur durch, wenn es (mit Hilfe von speziellen Properties, wie svn:mime-type und svn:keywords) dazu aufgefordert wird. Ansonsten behandelt Subversion Text- und Binärdateien gleich. Das wichtigste daran ist wohl, dass es für Text- und Binärdateien denselben Diff-Algorithmus benutzt, um unterschiedliche Dateiversionen differentiell zu speichern. Hendrik Schober, 09.06.2009 4/12 SVN für CVS-Benutzer.doc

Überblick SVN für CVS-Benutzer Beim Hinzufügen von Dateien zum Repository (import und add) versucht Subversion herauszufinden, ob die Dateien binär sind und setzt das entsprechende Property (svn:mime-type, s. 2.3, S. 7). 1.5.7. Lokale Änderungen Der aktuelle Zustand einer Working-Copy (lokale Änderungen) kann mit dem Status- Kommando abgefragt werden. Dieses ersetzt das bei CVS übliche cvs -n update. Mit einem Switch überprüft das Status-Kommando auch, welche Änderungen im Repository noch nicht (per Update) in die lokale Working-Copy integriert sind. Subversion hat auch ein revert-kommando, das es ermöglicht, Änderungen in Dateien oder ganzen Verzeichnissen in der Working-Copy rückgängig zu machen. 1.5.8. Offline arbeiten Aufbauend auf der Überlegung, dass Festplattenplatz heutzutage relativ billig ist, Netzzugang hingegen oft noch problematisch, legt Subversion die Original-Versionen sämtlicher ausgecheckter Objekte (versteckt) in der Working-Copy ab. Damit können Operationen wie der Vergleich veränderter Dateien mit der Originaldatei oder das Verwerfen von Änderungen auch offline durchgeführt werden und Änderungen zwischen Server und Working-Copy können immer als Diff gesendet werden. 1.6. Konzepte 1.6.1. Repositories Anders als CVS kennt Subversion keine Projekte. Ein Repository ist einfach ein versioniertes virtuelles Dateisystem. Ein Repository kann ein Projekt enthalten, viele Projekte oder alle Projekte einer Firma oder Organisation. Diese können direkt unter der Wurzel des virtuellen Dateisystems aufgeführt sein oder auch unterhalb weiterer Gliederungen. Oft existieren unterhalb eines Projektes die drei Verzeichnisse trunk, tags und branches, unter denen der Trunk des Projektes, alle Tags und alle Branches gespeichert sind. Diese Struktur ist zwar üblich, aber nicht erforderlich. Wo es Sinn ergibt, kann man durchaus davon abweichen. So könnte es z.b. denkbar sein, dass mehrere Projekte stark miteinander verzahnt sind, so dass Tags und Branches immer für alle Projekte gleichzeitig vergeben werden sollen. Auch können das Tag- und das Branch-Verzeichnis mit der Zeit sehr groß und unübersichtlich werden, weshalb es u.u. sinnvoll ist, sie weiter (z.b. durch Einfügen eines Unterverzeichnisses Releases) zu gliedern. 1.6.2. URLs Subversion -Repositories und die darin enthaltenen Verzeichnisse und Dateien werden per URL angesprochen. Der erste Teil der URL enthält das Protokoll gefolgt von einem Doppelpunkt. Zurzeit gibt es die Protokolle file (Repository im lokalen Dateisystem), svn (eigenes Protokoll von svnserve, einem mit Subversion ausgelieferten Server), http (per Apache-WebDAV), https (per Apache-WebDAV + SSL) und svn+ssh (svnserve per SSH-Tunnel). Nach dem Protokoll kommen der Server (eventuell mit Port), das Repository und der Verzeichnispfad, alle per / getrennt: svn://svn.example.com/repo/trunk/readme.txt. Es gelten die SVN für CVS-Benutzer.doc 5/12 Hendrik Schober, 09.06.2009

Tägliche Arbeit bekannten Regeln für den Lookup von URLs, weshalb man die hinteren Teile der Domain auch weglassen kann: svn://svn/repo/trunk/readme.txt. Eine ausgecheckte Working-Copy speichert die URL des Repositorys, zu dem sie gehört. Innerhalb einer Working-Copy kann man daher auch den ersten Teil der URL durch ein ^ ersetzen. Befinde ich mich z.b. in einem Verzeichnis, das eine Working- Copy von svn://svn/repo/trunk darstellt, kann ich auch ^/readme.txt schreiben. 2. Tägliche Arbeit 2.1. Das svn-kommando Auf der Kommandozeile bedient man Subversion mit dem Kommando svn. Das svn-kommando hat eine ganze Reihe Unterkommandos, die per svn subcmd aufgerufen werden. Viele der Unterkommandos haben Aliase, die oft kürzer sind (z.b. update/up oder checkout/co) oder auch einfach nur Alternativen darstellen (z.b. blame/praise/annotate/ann). Es gibt globale Optionen, die für alle Kommandos gültig sind und solche, die nur für spezielle gelten. Per svn help bekommt man eine Liste der möglichen Unterkommandos, per svn help subcmd Hilfe zu einem bestimmten Unterkommando. Die Ausgaben aller Kommandos sind bewusst so gestaltet, dass sie sich relativ leicht (z.b. von Skripten) parsen lassen. Die wichtigsten Kommandos (mit einigen wenigen Optionen) sind im Folgenden aufgelistet. Für diese Auflistungen gelten die folgenden Begriffe und Abkürzungen: Begriff URL Rev Path Bedeutung URL zu einem Repository URLs können absolut sein, relativ zur Repository-Wurzel (^/) oder relativ zum aktuellen Pfad (./ bzw.../) eine Revisionsnummer Pfad im Dateisystem (wo der Pfad optional ist, beziehen sich Operationen ohne Pfadangabe immer auf das aktuelle Verzeichnis ) Target entweder ein Pfad oder eine URL Src Dst ein Target, das als Quelle einer Operation dient ein Target, das als Ziel einer Operation dient 2.2. Checkout, update, checkin, revert Zu den alltäglichsten Handlungen gehören das Auschecken eines Projektes und das Holen der aktuellsten Änderungen aus dem Repository. Zum Auschecken dient das Kommando checkout: svn checkout URL[@Rev] [Path] Als Alternative gibt es auch das Synonym co, die vollständige Syntax wäre dann svn co URL[@Rev] [Path] Zum Updaten dient svn update [Path] (mit dem Synonym up). Hendrik Schober, 09.06.2009 6/12 SVN für CVS-Benutzer.doc

Tägliche Arbeit SVN für CVS-Benutzer Wird der Pfad weggelassen, so gilt wird aktuelle Verzeichnis als Working-Copy angenommen und die Repository-URL verwendet, die Subversion in den Metadaten der Working-Copy hinterlegt hat. Ähnlich wie bei CVS gibt das update-kommando eine ganze Reihe Indikatoren für jedes veränderte Objekt aus: U (Updated) Änderungen aus dem Repository geholt G (Merged) Änderungen im Repository in lokale Änderungen gemergt C (Conflict) Konflikt beim Mergen A (Added) Objekt hinzugefügt E (Existed) (hinzuzufügendes) Objekt existiert lokal schon D (Deleted) Objekt gelöscht Indikatoren in der ersten Spalte der Ausgabe beziehen sich auf die Dateien oder Verzeichnisse selbst, Indikatoren in der zweiten Spalte auf deren Properties. Beim Auschecken und Updaten eines Projektes kann man eine Rekursionstiefe mit angeben. Möglich sind empty, files, immediates und infinity. Dies hilft, wenn man nur bestimmte Teile eines Baumes auschecken möchte. (So könnte man z.b. svn://svn.example.com/my_rep/tags/releases mit der Rekursionstiefe immediates auschecken und würde bei regelmäßigen Updates alle neue erzeugten Release-Tags mitbekommen.) Lokal veränderte Objekte können per svn commit m "checkin comment" [Path] (Synonym ci) in das Repository eingecheckt werden. Ausversehen eingecheckte Änderungen können mithilfe des merge-kommandos wieder rückgängig gemacht werden (s. 3.2.4, S. 10, der Fehler bleibt jedoch im Repository). 2.3. Import, add, delete, revert Eine existierende Verzeichnisstruktur kann man mit svn import [Path] URL in ein Repository übernehmen. Die Dateien und Verzeichnisse unter Path (falls keiner angegeben wurde, das aktuelle Verzeichnis) bleiben dabei unverändert, werden also nicht zu einer Working-Copy. Zum Arbeiten muss man die importierten Objekte daher neu auschecken. Mittels svn add [Path] können einzelne Dateien bzw. Verzeichnisse zur Working-Copy hinzugefügt, mittels svn delete [Target] (Synonyme: del, remove, rm) aus der Working-Copy gelöscht werden. Beides sind Änderungen, die per svn commit an das Repository übertragen werden müssen. Lokale Änderungen, die noch nicht eingecheckt wurden, können per svn revert [Path] rückgängig gemacht werden. (Dies erfordert natürlich eine gewisse Vorsicht, weil es nicht eingecheckte Änderungen u.u. unwiederbringlich löscht.) Beim Hinzufügen von Dateien versucht Subversion, einige sinnvolle vordefinierte Properties zu setzen. Dazu gehören svn:executable (falls es eine ausführbare Datei ist) und svn:mime-type. Das svn:mime-type Property dient im Wesentlichen zur Unterscheidung zwischen Text- und Binärdateien und ist daher relativ wichtig. Die automatisch getroffenen Entscheidungen sollten vor dem SVN für CVS-Benutzer.doc 7/12 Hendrik Schober, 09.06.2009

Tags und Branches Einchecken überprüft und gegebenenfalls korrigiert bzw. ergänzt (insbesondere durch svn:eol-style) werden. Weitgehend ersparen kann man sich manuelle Korrekturen durch sinnvolles Editieren des Abschnittes [auto-props] in Subversions config-datei. 2.4. Weitere interessante Befehle Das schon erwähnte svn status (Synonyme: stat, st) zeigt den aktuellen Zustand der Working-Copy an. Ein svn log [Path] zeigt alle Änderungen bezüglich des als Path angegebenen Objektes an (bzw. des aktuellen Verzeichnisses, wenn nichts angegeben wurde). svn diff [Target] zeigt Unterschiede zwischen zwei URLs, zwei Pfaden oder einer URL und einem Pfad an. Mittels svn cat und svn list kann man sich die Inhalte von Dateien bzw. Verzeichnissen anzeigen lassen. 3. Tags und Branches 3.1. Anlegen von Tags und Branches Anlegen lässt sich ein Tag bzw. Branch per svn copy [Src] [Dst] (Synonym: cp) Ist auf der rechten Seite (Dst) eine URL, wird die Änderung sofort eingecheckt. (Dann sollte mittels m eine Commit-Message angegeben werden.) Ist dort ein Pfad, wird dieser erzeugt und muss per Commit explizit ins Repository übertragen werden. Soll ein Tag oder Branch erzeugt werden, der reine Kombination von Objekten mit verschiedenen Revisionsnummern enthält, kann man diese in einer Working-Copy erzeugen, indem man in dieser Dateien und Ordner (per svn up -r Rev Path) selektiv auf einen bestimmten Stand bringt und dann (per svn cp. URL) eine Kopie dieses Standes erstellt. Per svn switch URL kann man die aktuelle Working-Copy zwischen verschiedenen URLs hin- und herschalten. (Das ist meist schneller als das erneute Auschecken eines Branches, da nur die Unterschiede zwischen den Branches vom Server geholt werden müssen.) Die Ausgabe des Kommandos ist ähnlich der des update-kommandos. 3.2. Mergen 3.2.1. Arten von Merge-Operationen Üblicherweise werden Release-Branches (zur Weiterentwicklung bestimmter Releases) und Feature-Branches (zur Entwicklung bestimmter Features) angelegt. Beim Mergen wird dabei zwischen dem Mergen einzelner oder mehrerer Änderungen (z.b. einzelner Bugfixes aus dem Trunk in einen Release-Branch oder aller aktueller Änderungen auf dem Trunk in einen Feature-Branch) und der Reintegration, dem Mergen aller Änderungen eines Feature-Branches zurück in den Trunk, unterschieden. Das Problem im letzteren Fall ist, dass eventuell schon Änderungen aus dem Trunk in den Branch gemergt worden sind. Würden diese nun wieder in den zurück in den Trunk gemergt, gäbe es Konflikte, da diese Changesets dort ja schon vorhanden sind. Hendrik Schober, 09.06.2009 8/12 SVN für CVS-Benutzer.doc

Tags und Branches SVN für CVS-Benutzer Bei der Reintegration eines Branches will man also beim Mergen alle Changesets überspringen, die bei früheren Merge-Operationen aus dem Ziel der Reintegration in die Quelle kopiert wurden. 3.2.2. Einfaches Mergen Mittels svn merge Src [Dst] kann man alle Änderungen aus einem Branch (Src) in eine Working-Copy (Dst) mergen. Das merge-kommando gibt dabei ähnliche Rückmeldungen wie das update-kommando. Ist Dst ein Pfad, müssen die Änderungen per Commit an das Repository übertragen werden. Ein svn merge Src [Dst] c Rev mergt nur einen bestimmten Changeset, ein svn merge Src [Dst] r Rev1:Rev2 einen bestimmten Bereich von Changesets. Es ist i.a. nicht sinnvoll, in eine Working-Copy zu mergen, die noch nicht eingecheckte Änderungen hat. Merge-Operationen können Konflikte verursachen, die manuell gelöst werden müssen, und das unbeabsichtigte Mergen falscher Changesets kann die Working-Copy völlig mit solchen Konflikten kontaminieren. Der einfachste Ausweg aus diesem Problem ist svn revert das sich bei nicht eingecheckten Änderungen aber verbietet. Dann müssen die eigenen Änderungen erst mühsam wieder aus dem Wust von Konflikten herausoperiert werden, was sehr zeitraubend und fehleranfällig ist. Will man dennoch unbedingt mergen, sollte man erst einmal testen, ob eine Merge- Operation viele Konflikte erzeugen würde, bevor man sie startet. Dazu dient die Option --dry-run: svn merge Src [Dst] --dry-run Dies zeigt alle Änderungen an, die beim Mergen vorgenommen werden würden, führt sie aber nicht aus. Seit Version 1.5 legt Subversion Informationen über die Merge-Operation in den Properties ab, so dass spätere Merge-Operationen mit gleicher Quelle und gleichem Ziel (anders als CVS) nicht wieder die gleichen Änderungen mergen und damit zu Konflikten führen. Hat man z.b. einen Feature-Branch, kann man Änderungen aus dem Trunk mittels svn merge ^/trunk immer wieder aufs Neue mergen, ohne sich darüber Gedanken machen zu müssen, welche Changesets schon bei früheren Merge-Operationen gemergt wurden. Wer schon einmal versucht hat, die dazu benötigten Daten für das selektive Mergen von Änderungen zwischen mehreren CVS-Branches von Hand zu verwalten, wird das sehr zu schätzen wissen. Mittels svn mergeinfo Src [Dst] kann man sich die von Subversion gespeicherten Informationen darüber anzeigen lassen, welche Revisionen schon von der angegebenen Quelle gemergt wurden. 3.2.3. Reintegration Ist die Entwicklung auf einem Feature-Branch abgeschlossen, kann man alle seine Änderungen mit svn merge --reintegrate ^/branches/feature_x SVN für CVS-Benutzer.doc 9/12 Hendrik Schober, 09.06.2009

Administration in den Trunk übernehmen. Danach ist dieser Branch für automatisches Mergen nicht mehr benutzbar. Soll auf diesem Branch noch weiterentwickelt werden, sollte man ihn daher lieber löschen und (als Kopie des Merge-Ziels) neu erzeugen. 3.2.4. Commit rückgängig machen Hat man Änderungen ausversehen eingecheckt, kann man diese durch mergen des negativen Changesets dieses Checkins rückgängig machen: svn merge c -Rev Die Angabe eines - vor der Revisionsnummer sorgt dafür, dass die Unterschiede zwischen der Revision Rev und Rev-1 in die aktuelle Working-Copy gemergt werden. (Stattdessen kann auch svn merge Src [Dst] -r Rev:Rev-1 benutzt werden.) Ungewollte Lösch-Operationen können auch mittels des copy-kommandos rückgängig gemacht werden: svn copy URL@Rev Path Dies kopiert das Objekt an der URL URL, wie es zum Zeitpunkt der Revision Rev existiert hat, in den Pfad Path inklusive seiner gesamten History. 3.2.5. Logging von Branches Schaut man sich mittels svn log die History eines Objektes an, kann man --use-merge-history (oder auch -g) verwenden, damit der log-befehl für Änderungen, die durch Mergen in einen Branch gekommen sind, als solche gekennzeichnet mit anzeigt. 4. Administration Subversion kommt mit einer Anzahl zusätzlicher Programme, unter denen in erster Linie wohl svnadmin und svnserve zu erwähnen sind. svnadmin hat Unterkommandos zum Erzeugen von neuen Repositorys und von Repository-Kopien im laufenden Betrieb, zum Schreiben und Lesen von Dump-Files u.a.m. svnserve implementiert einen Server für das svn://-protokoll (s. 1.6.2, S. 5). 4.1. Backups Das wichtigste administrative Thema ist sicherlich die verwendete Backupstrategie. Hier bietet Subversion eine große Menge von Möglichkeiten. Hotcopy Entscheidende Voraussetzung für ein funktionierendes Backup ist ein konsistenter Stand des Repositorys. Damit das Repository für die Zeit des Backups nicht gesperrt werden muss, sollte erst einmal eine (konsistente) Kopie des Repositorys angelegt werden. Dazu lässt sich das svnadmin-kommando benutzen: svnadmin hotcopy path-to-repo path-to-backup-repo Dieses Kommando erstellt eine voll benutzbare Kopie des Repositorys unter path-to-backup-repo. Diese Kopie lässt sich dann mit üblichen Mitteln auf Dateisystem-Ebene sichern. Dumps Mit svnadmin lassen sich auch Dumps des Repositorys schreiben und lesen. Auch diese können für ein Backup auf Dateisystem-Ebene verwendet werden. Solche Dumps lassen sich sogar inkrementell erstellen und eignen sich daher z.b., als Post-Commit-Hook verwendet zu werden. (Jeder Commit wird sofort als inkrementeller Dump gesichert. Beim Wiederherstellen wird erst die letzte Hendrik Schober, 09.06.2009 10/12 SVN für CVS-Benutzer.doc

Administration SVN für CVS-Benutzer vollständige Sicherung, dann die inkrementellen Sicherungen der einzelnen Checkins seit der vollständigen Sicherung wiederhergestellt.) Ein Nachteil dieser Strategie ist, dass das Laden von Dumps u.u. recht lange dauern kann. Außerdem fehlen den Dumps sämtliche Daten (z.b. Benutzerrechte), die nicht durch Checkins gesichert werden. (Ein anderer, subtilerer Nachteil ist, dass Änderungen an Revisions-Properties bereits gesicherter Revisionen beim inkrementellen Sichern nicht beachtet werden.) svnsync Das svnsync-kommando ist ein weiterer Weg, um eine Kopie eines Repositorys zu erhalten. Es spielt alle Checkins eines Repositorys in ein speziell dafür angelegtes anderes Repository ein, das damit ein identisches Replikat des ersten wird. Diese Kopie kann im Falle eines Problems sofort das Original ersetzen. Ansonsten hat es aber dieselben Nachteile wie das Sichern von Dumps (s., S. 10). Eine gute Backup-Strategie wäre sicherlich das regelmäßige Sichern einer Hotcopy, eventuell ergänzt um inkrementelle Backups, die von einem Post-Commit-Hook angestoßen werden. 4.2. svnserve svnserve ist ein sehr einfacher Weg, einen Subversion-Server aufzusetzen, ohne einen Apache-Server oder einen SSH-Tunnel konfigurieren zu müssen. Das Subversion-spezifische Protokoll ist relativ schnell, Benutzer brauchen keinen Account auf dem Server und Passworte werden nicht übertragen. Auf der anderen Seite gibt es nur eine Methode der Authentifizierung, der Netzwerk- Verkehr sowie das Speichern der Passworte auf dem Server geschehen unverschlüsselt (all das lässt sich per SASL Simple Authentication and Security Layer auch ändern, nur ist das Aufsetzen eines Servers dann nicht mehr ganz so leicht) und der Server hat keinerlei Logging-Möglichkeit. Wer mit diesen Nachteilen leben kann, für den ist svnserve eine gute Lösung, die mit sehr wenig Mühe implementiert ist und einen späteren Umstieg auf eine andere Lösung erlaubt. Auf Windows kann man svnserve von der Kommandozeile starten oder als Service einrichten. Letzteres ist sicherlich der bessere Weg. Dieser Aufruf sc create svn binpath= "C:\svn\svnserve.exe --service -r C:\repo" displayname= "Subversion Server" depend= Tcpip start= auto (alles in einer Seite) erzeugt einen automatisch startenden Service svn, der C:\bin\svnserve.exe für das Repository C:\repo ausführt. Falls der Pfad zu svnserve Leerzeichen enthält, müssen diese durch ein zusätzliches Paar von Anführungszeichen gesichert werden: sc create svn binpath= "\"C:\Program Files\svn\svnserve.exe\"..."... Der Service kann dann mit dem net-kommando administriert werden net stop svn net stop svn SVN für CVS-Benutzer.doc 11/12 Hendrik Schober, 09.06.2009

5. 3rd-Party Tools 3rd-Party Tools Es gibt eine Unmenge von Tools für Subversion, wobei graphische Clients wohl die beliebtesten sind. Auf Windows ist TortoiseSVN (s. Link unter 6, S. 12) sicherlich der am weitesten verbreitete graphische Subversion-Client. (Er wird u.a. auch von SourceForge empfohlen.) Er klinkt sich genau wie TortoiseCVS in den Explorer ein, stellt den Status der einzelnen Dateien und Verzeichnisse durch Overlay-Icons im Explorer sowie im Eigenschaften-Dialog von Dateien und Verzeichnissen dar und erlaubt Operationen per Kontextmenü. TortoiseSVN bildet im Wesentlichen die Funktionalität des svn-kommandos ab, obwohl es auch ein paar eigene Dinge mitbringt (v.a. Programme für textuelle und binäre Diffs und Funktionalität zum Erzeugen und Einspielen von Patches). Im Gegensatz zu TortoiseCVS lässt TortoiseSVN im Hintergrund einen eigenen Prozess laufen (TSVNCache.exe), der ständig die Icons der Ordner aktualisiert. Das bringt u.u. Performance-Einbußen mit sich, weshalb es in den Optionen auch abschaltbar ist. Ein weiteres interessantes Tool für Windows ist AnkhSVN (zu finden unter s. Link unter 6, S. 12), das Subversion in Visual Studio integriert. 6. Ausgewählte Links Subversion http://subversion.tigris.org SVN Book http://svnbook.red-bean.com TortoiseSVN http://www.tortoisesvn.org AnkhSVN http://ankhsvn.open.collab.net Hendrik Schober, 09.06.2009 12/12 SVN für CVS-Benutzer.doc