Subversion Schulung

Schulung

„Subversion“

© 2008 - 2009 Jörn Dinkla

joern@dinkla.com
http://www.dinkla.com

A lot of diagrams are copied from the online subversion
book (see the references at the end of the document).
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com

Vorstellung
• Dipl.-Inform. Jörn Dinkla
• Schwerpunkte
• Java Entwicklung (J2SE, JEE)
• Moderne Programmiersprachen
• Groovy, Ruby, Haskell, Scala
• Modellgetriebene Entwicklung
• Automatisierung
• Eclipse
• Plugin-Entwicklung
• CUDA, OpenCL
• Hobbies
• Musik, Literatur

© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 2

Überblick


Überblick
• Versionsverwaltung
• Subversion
• Grundlagen
• Praxis
• Benutzung bei typischen Arbeitsschritten
• Fortgeschrittene Praxis
• Installation und Konfiguration

• Zwischendurch
• Hands-on
• Gemeinsam benutzen, installieren, konfigurieren


Versionsverwaltungen


Versionsverwaltungen
• Ähnlichkeit zu einem Fileserver oder Dateisystem
• Aber: zusätzlich die zeitliche Dimension
• Ein Dateisystem mit Gedächtnis

• „persistente“ Datenstruktur [CLR90]


Versionsverwaltung
• Unterschiedliche Namen
• Revision Control System
• Version Control System (VCS)
• Source Code Management (SCM)


Versionsverwaltung
• Protokollierung von Änderungen
• „Wer hat was wann geändert?“
• Wiederherstellung von alten Zuständen
• „Das hat doch schon mal funktioniert!“
• Archivierung der Releases
• Gleichzeitige Entwicklung mehrere Varianten
• Neue Entwicklung
• Fehlerbehebung bei älteren Versionen
• Koordinierung des gemeinsamen Zugriffs
• „collaborative editing and sharing“


Theoretische Grundlagen
• Unterschiede zwischen Versionsverwaltungen
• Repository-Modell
• Speicherung von Entitäten
• Verzeichnisse, Dateien, Symbolische Verweise
• Mögliche Operationen:
• Beispiel: Umbenennen von Dateien
• Kontrolle des Zugriffs
• Sperren, Locks
• Atomare Transaktionen
• Metadaten
• Konfigurierbarkeit
• Schnittstellen für Administratoren und Benutzer


Repository-Modell
• Zentral
• Client-Server
• Repository auf dem Server
• Auf dem Client nur Arbeitskopien

Repositor

Commit Checkout
Update

User A User B User C


Repository-Modell
• Verteilt
• Jeder hat ein Repository
• Bzw. nur noch Arbeitskopien
• Vollständige Funktionalität ohne Netzverbindung
• Commits, Branches usw.
• Zentrales Repository nur noch für Backups

User A User C

Repositor
User B


Architektur
• Dimensionen eines Repositories
• Projekt (P wie „project“)
• Pfad (L wie „location“)
• Zeit (T wie „time“)

• Addressierung
• P: L, T (CVS)
• Jedes Dokument wird einzeln versioniert
• P: T, L (SVN)
• Der gesamte Baum wird versioniert
• Implikationen
• Umbenennen von Dateien und Verzeichnissen

Kontrollierte Zugriff
• Mehrere Benutzer
• Gleichzeitige Änderungen ?
• Überschreiben von Informationen ?
• Kontrolle
• Zugriff
• Locks / Sperren
• lock-modify-unlock
• Änderungen
• Konflikte
• copy-modify-merge


Zugriff: Lock-Modify-Unlock
• Vor dem Bearbeiten
• Sperren

• Nach dem Bearbeiten
• Entsperren


Zugriff: Lock-Modify-Unlock
• Nachteile
• Ist sehr restriktiv
• Mitarbeiter lockt Datei und geht in den Urlaub
• Unnötigerweise sequentiell
• Nur einer kann eine Datei bearbeiten
• Lock auf Dateiebene
• „Falsche Sicherheit“
• Abhängigkeiten werden nicht berücksichtigt
•Entwickler ändert Klasse A
•Ein Anderer ändert Klasse B
•Beide checken zeitgleich ein
•Code läuft nicht mehr, da A und B voneinander
abhängen

Zugriff: Copy-Modify-Merge
• Gleichzeitige Änderungen


• Harry merged die Änderungen


• Auflösen eines Konflikts
• Manuelles Auflösen pro geändertem Bereich
• Vorteile
• Konflikte sind relativ selten
• Benutzer können parallel an Dateien arbeiten
• Locking wird dennoch benötigt
• Nicht „mergebare“ Dateitypen
• Binäre Dateien, Bilder, Fotos, etc.


Eine kurze Geschichte
• Source Code Control System (SCSS)
• 1972 Bell Labs
• Revision Control System (RCS)
• Anfang der 80er, Walter F. Tichy
• Concurrent Versions System (CVS)
• Mitte 80er
• Subversion
• Ein besseres CVS
• Entwicklung seit Anfang 2000
• Version 1.0 im Februar 2004
• Verteilte Systeme (Distributed, DVCS)
• Werden seit 2004 entwickelt

Kommerzielle Produkte
• Eine Auswahl, alphabetisch sortiert
• BitKeeper (BitMover Inc.)
• ClearCase™ (IBM)
• Continuus™
• Perforce™ (Perforce Software Ltd.)
• PVCS™
• StarTeam™
• VisualSourceSafe™ (Microsoft)
• Produkte mit integrierter Versionsverwaltung
• Microsoft Word(TM)
• Open Office
• Wiki‘s

Neue Entwicklungen
• SVK
• Ergänzung zu Subversion

• Verteilte Systeme
• Bazaar
• Mercurial
• Git
• Monotone
• Darcs


Subversion


Architektur von Subversion
• GUI

• Client

• Netzwerk

• Server

• Repository
• Speicher


Subversion
• Adressierung
• P: T, L
• Der gesamte Baum wird versioniert
• Versionierung von
• Verzeichnissen
• Dateien
• Symbolischen Verweisen
• Echte Versionshistorie
• Atomare Commits
• Versionierte Metadaten
• „Billige Kopien“
• Flexible Netzwerkschicht


Subversion
• Arbeitskopie
• SVN speichert in .svn ausgescheckte Kopie
• Änderungen können auch ohne Verbindung zum
Repository festgestellt werden
• Nachteil: Speicherplatzverdopplung
• SVN verwaltet Inhalte in
• FSFS (seit 1.1)
• Berkeley DB
• Repository-Inhalte werden komprimiert
• „deltification“, „deltified storage“
• Binärer 3-Wege-Differenzalgorithmus (seit 1.2)
• Identisch für Text und Binärdateien

Geschichte
• Subversion
• 1.0 CVS-Ersatz
• 1.1 2004/09 FSFS, Symbolische Links
• 1.2 2005/05 Sperren, binärer Differenzalgorithmus
• 1.3 2005/12 Pfadbasierte Autorisierung, API-Bindings
• 1.4 2006/09 Replizierung, Metadaten überarbeitet
• 1.5 2008/06 Verbesserungen B&M, SASL,
Authentifizierung
• 1.6 2009/05 Konfliktbearbeitung
• URL
• http://subversion.tigris.org/
• http://svnbook.red-bean.com/


Clients
• Für die Arbeit mit Subversion gibt es viele Möglichkeiten
• Kommandozeile
• svn, svnadmin, svnserve, etc.
• Integration in den Desktop
• TortoiseSVN (Windows)
• SCPlugin (Mac OS X)
• KSvn (Linux KDE)
• Standalone-Programme
• RapidSVN
• Integration in IDE
• Eclipse, NetBeans, VisualStudio, etc.


Clients: GUI
• Auswahl: RapidSVN und Eclipse


Clients: WebSVN
• Zugriff mit WebSVN


Clients: Kommandozeile

• Alle Programme
• Für „normale“ Benutzer ist nur svn wichtig
svn Das Programm für Benutzer
svnadmin Das Programm für Administratoren
svnlook Werkzeug zur Administration
svnsync Backup / Spiegeln eines Repositories
svnserve Subversion-Server
svndumpﬁlter Administration, Dumps von
Repositories
svnversion Gibt die Revisionsnummern an
mod_dav_svn Plugin für den Apache HTTP-Server

Kommandozeilenargumente
• Für die meisten Programme gibt help eine Übersicht.
• Beispiele
• svn help
• svn help checkout

• Kommandozeilenargumente
• Kurze Version
• -s
• Lange Version
• --eine-lange-option
• Nicht für alle Argumente gibt es eine kurze Version


Repositories und URLs
• Abbildung zwischen URL und Dateien im Repository
• svn://localhost/test1/trunk/beispiel-java/build.xml


Repositories und URLs
• URL:
• PROTOKOLL://HOST [:PORT]/REPOSITORY/PFAD

• Unterstütze Protokolle
• file, http, https, svn, svn+ssh

• Standard-Port: 3690

• Beispiele
• svn://localhost/testrepository/trunk/projekt/bilder
• http://svn.collab.net/repos/svn/trunk/


Typische Arbeitsschritte
• Einmalig: Projekt auschecken
• Arbeiten
• svn add, svn delete, svn copy, svn move
• Synchronisieren
• Aktualisieren
• svn update
• Änderungen rückgängig machen
• svn revert
• Konflikte lösen
• svn update
• svn resolved
• Änderungen schreiben
• svn commit

Projekt auschecken
• Auschecken
• svn checkout URL@REV PFAD
• Es wird eine lokale Arbeitskopie erstellt
• Gewöhnliches Verzeichnis
• Dateien können editiert werden
• Achtung bei Löschen/Verschieben
•svn copy, move und delete benutzen
• Enthält .svn Verzeichnis
• Nicht ändern oder löschen !!!
• Enthält Kopie der Dateien/Verzeichnisse
•Speicherplatz verdoppelt
• Dadurch Netzwerkunabhängig


Arbeitskopie
• Für jede Datei wird gespeichert
• Ausgecheckte Revisionsnummer, „working revision“
• Zeitpunkt der letzten Änderung durch das Repository

• Informationen
• svn info
• svn status
• svn status --verbose
• svn list
• svn diff
• svn log
• svn cat

Arbeitskopie: Zustände
• Änderungen möglich
• Lokal in der Arbeitskopie
• Im Repository
• Daher: Vier Zustände einer Datei / eines Verzeichnisses

Arbeitskopie Arbeitskopie
unverändert geändert

Repository
Commit
unverändert
Update
Repository
Update Konﬂikte lösen
geändert
Commit

Arbeitskopie: Zustände
• Ausgabe von svn status -u

? scratch.c
A stuff/loot/bloo.h
C stuff/loot/lump.c
D stuff/ﬁsh.c
M bar.c

• Erklärung
• A Hinzugefügt, „addition“
• C Konflikt, „conflict“, Muss gelöst werden, „resolve“
• D Gelöscht, „deletion“
• M Geändert, „modified“

Arbeiten
• svn add DATEINAME
• Fügt Datei hinzu
• svn delete DATEINAME
• Löscht eine Datei
• svn copy DATEINAME1 DATEINAME2
• Kopiert eine Datei
• svn move DATEINAME1 DATEINAME2
• Verschiebt eine Datei
• svn mkdir VERZEICHNISNAME
• Erstellt ein Verzeichnis


Synchronisieren
• Neue Versionen müssen explizit geholt werden
• svn update

• Lokale Änderungen müssen explizit committed werden
• svn commit

• Löschen nur, wenn aktuell
• Änderungen an Metadaten nur, wenn aktuell


Konﬂikte lösen
• Falls update auf einen Konflikt stösst, muss dieser gelöst
werden
• Ab 1.5 per Kommandozeile interaktiv möglich
• Besser: Die IDE‘s bieten hier gute Unterstützung.
• assertTrue(result.length() > 0);
• <<<<<<< .mine
• result = Doctor.answer("XGSHDHDHDHHDHDHXHHS");
• =======
• result = Doctor.answer("A very, very long String. A very, very long
String. A
• very, very long String. A very, very long String. ");
• >>>>>>> .r18
• assertNotNull(result);


Konﬂikte lösen
• Bei einem Konflikt gibt es die folgenden Möglichkeiten
• Aufschieben
• Version aus Arbeitskopie übernehmen
• Version aus Repository übernehmen
• Dateien ineinanderführen, „mergen“


Konﬂikte lösen
• Bei einem aufgeschobenen Konflikt werden die folgenden
Dateien angelegt.
• DATEINAME.mine
• Die Datei vor dem Update
• DATEINAME.rOLDREV
• Die Datei des letzten Updates
• DATEINAME.rNEWREV
• Die aktuelle Datei im Repository


Sperren
• Sicherstellen, dass nur ein einzelner Zugriff auf eine Datei
hat, „mutual exclusion“
• Binäre Dateien, z. B. Bilder
• Syntax
• svn lock PFAD
• svn unlock PFAD
• Wichtig:
• Nach einem Commit werden alle Locks aufgehoben
• Locks können wieder aufgehoben werden
• svn unlock --force PFAD
• Attribut svn:needs-lock
• Die Datei ist dann nur lesbar, nur nach dem Sperren
beschreibbar

Weitere Arbeitsschritte
• Anlegen
• einer Marke, „tag“
• eines Zweiges, „branch“
• eines neuen Projekts

• Zusammenführen von Zweigen, „merge“


Branching und Taggen
• Mehrere Versionen
• Feature
• Version / Release
• Vendor

• Konventionen
• Entwicklung gegen trunk
• „HEAD“, „BASE“
• Tags kommen in den Ordner tags
• Die Dateien werden nicht mehr modifiziert
• Zweige kommen in den Ordner branches


Ablauf der Softwareentwicklung
• Neueste Entwicklung im /trunk
• Wenn eine Version 1.0 fertiggestellt wurde
• Erstellung eines Branches in /branches/v1.0
• Parallel
• Entwicklung von 1.1 im /trunk
• Test und QA in /branches/v1.0
• Evtl. Merges zurück in den /trunk
• Ausliefierung
• Markierung in /tags/v1.0

• /trunk und /branches sind Arbeitsbereiche
• Im Verzeichnis /tags wird nichts geändert


Kopien bei Subversion
• Billige Kopien
• „Cheap Copies“
• O(1) Platz und Zeit

• Interpretation einer Kopie
• als Zweig, „branch“
• als Markierung, „tag“

• Bei Tags werden keine
• Änderungen mehr durchgeführt


Einen Zweig anlegen
• Mit svn copy können Kopien angelegt werden
• svn copy SOURCE@REV DEST

• Möglichkeiten
• Arbeitskopie -> Arbeitskopie
• Arbeitskopie -> Repository
• Repository -> Arbeitskopie
• Repository -> Repository

• Beispiel
svn copy svn://host/repo/trunk
svn://host/repo/branches/version-1.0
-m „Version 1.0“


Zusammenführen / Mergen
• Ein Zweig kann in einen anderen überführt werden
• Merge
• In Version 1.5 wesentlich verbessert
• Daher hier: 1.5 Client und Server
• Warnung: Zweige können sich auch zu weit voneinander
entfernen
• Daher regelmäßig mergen


Changesets
• „changeset“
• Mit Namen identifizierte Menge von Änderungen
• Änderungen
•Dateien
•Verzeichnisbaum
•Metadaten
• Ein „patch“ mit einem Namen
• Die Änderungen von Revision N-1 zu N

• svn log -r REV
• svn diff -c REV
• svn merge -c REV


• Annahme: Branch updaten, trunk zu branch
• Wichtig: Keine lokalen Änderungen
•svn status
• svn merge trunk
• Untersuchen
• svn status
• svn diff
• Bauen und testen oder rückgängig machen
• svn revert -R
• Besser als „patch“
• Strukturänderungen, Metadaten
• Historie
• Erneuter Aufruf merged nur die jeweils neuen

• Den Branch zurück in den Trunk
• svn co trunk
• svn update
• svn merge --reintegrate branchurl
• --reintegrate notwendig
• Da es wieder in den Ursprungszweig geht
• Nur die Änderungen des Branches
• Nicht die aus dem Trunk entnommenen
• Prüfen
• svn commit
• Evtl.
• svn delete branchurl
• Geschichte bzw. logs bleiben erhalten

• Informationen werden von Subversion gespeichert
• svn:mergeinfo

• Zugriff mit
• svn mergeinfo
• svn mergeinfo --fromsource

• Ein Merge kann auch nur getestet werden
• svn merge --dry-run


• Cherrypicking, „backporting“
• Auswahl von Changesets (nicht alle) mergen
• Beispiel:
• Bestimmte Sammlung von Bug-Fixes aus dem Trunk zu
Version 1.0
• svn merge -c REV URL


Undo
• Falls ein Commit einen Fehler enthielt

• „Rückgängig“ machen mit

• svn merge --revision 303:302
• svn merge --change -303
• svn merge -c -303

• Das Changeset wird „rückwärts“ angewendet

• Achtung: Das Repository enthält die vollständige
Geschichte
• Der Commit ist in der Geschichte noch vorhanden

Fortgeschrittene Themen


Revisionsnummern
• Sind in Interval spezifizierbar
• -r REV1:REV2

• Symbolische Revisionsnummern
• HEAD
• Die aktuellste Version im Repository
• BASE
• Die Versionsnummer der lokalen Kopie
• COMMITTED
• Revision der letzten Änderung
• PREV
• COMMITTED - 1


Revisionen
• Revisionen sind auch als Datum spezifizierbar
• Datumsformat nach ISO-8601

• Die Revision vom 17.06.2008
• svn checkout -r {2008-06-17}
• Die Revision von 15 Uhr 30
• svn checkout -r {15:30}
• Die Unterschiede der Revisionen vom 17. bis zum
20.06.2008
• svn diff -r {2008-06-17}:{2008-06-20}

• Achtung:
• Zeitstempel von Entitäten können geändert werden

Metadaten
• Metadaten, „properties“
• Versioniert
• Verzeichnisse, Dateien
• Unversionierte
• Revisionen

• Schlüssel-Wert-Paare
• Frei definierbar
• svn:mime-type=text/plain
• mein-property=Bug#123
• Mit Präfix svn: sind von Subversion reserviert

• Konflikte werden ähnlich wie bei Dateien gehandhabt

Metadaten
• Manipulation von Metadaten
• Setzen
• svn propset NAME WERT DATEI
• svn propset NAME -F DATEINAME DATEI
• Editieren
• svn propedit NAME DATEI
• Anzeigen
• svn proplist [-v] DATEI
• svn propget NAME DATEI
• Löschen
• svn propdel NAME DATEI
• Nur lineare Suche möglich
• Schlechte Performanz

Eigenschaften von Dateien
• svn:mime-type
• Für binäre Typen wird z. B. kein Merge/Resolve
angeboten
• *.oldrev BASE-Revision
• *.newrev
• svn:executable
• Ist Datei ausführbar (das +x Flag von chmod)
• svn:eol-style
• Zeilentrennsymbol: native, CRLF, LF, CR


Ignorieren von Dateien
• Bestimmte Dateien sollen nicht ins Repository
• Temporäre Dateien
• Dateien, die Passwörter enthalten
• Generierte bzw. kompilierte Dateien
• Backup-Dateien (*.bck, *~)
• Möglichkeiten
• Runtime Configuration Area
• Attribut global-ignores
• Liste von Dateimustern, durch Leerzeichen getrennt
• Metadaten-Eigenschaft für ein Verzeichnis
• svn:ignore
• Funktioniert ähnlich wie .cvsignore


Ersetzung von Schlüsselwörtern
• In Dollarzeichen eingeschlossen
• Schlüsselwörter
• Date, LastChangedDate
• Revision, Rev, LastChangedRevision
• Author, LastChangedBy
• HeadURL, URL
• Id

• Wird nur aktiv, wenn das Attribut svn:keywords gesetzt
wurde
• svn propset svn:keywords „Date Author“ DATEI


Beschränkung der Tiefe
• Seit 1.5 kann die Verzeichnistiefe spezifiert werden
• „sparse directories“

• Argumente
• --depth empty
• --depth files
• --depth immediates
• --depth infinity

• Mit --set-depth kann die Tiefe geändert werden.
• svn update --set-depth immediates PFAD


Externe Deﬁnitionen
• Metadaten-Attribut
• svn:externals

• Enthält Liste von „virtuellen“ Verzeichnissen

• icons svn://localhost/art/icons
• sounds -r69 svn://localhost/art/sounds

• Ermöglicht redundanzfreie Speicherung
• Allerdings
• Nicht für einzelne Dateien
• Nur absolute URLs
• Sind extern, commit muss explizit aufgerufen werden

Komplexe Tags
• Manchmal notwendig:
• Zusammenbasteln einer Distribution
• Sourcecode Version 1.0.3
• Bibliotheken auch, aber nicht das GUI
• Datenbanktreiber muss durch neueren ersetzt werden
• etc.
• Experimentelles Feature wurde implementiert
• Soll aber nicht in den Trunk

• Schreiben der Arbeitskopie in das Repository
• svn copy ARBEITSKOPIE URL


Peg-Revisionen
• Im Laufe der Zeit kann
• Ein Pfad mehrere Objekte kennzeichnen
• Ein Objekt mehrere Pfade haben
• Grund: Verschieben und Umbenennen
• Beispiel
• Datei angelegt, Gelöscht und wieder angelegt
• Lösung: Peg-Revision
• svn KOMMANDO [-r REV] PFAD@PEG-REV
> svn cat datei@28
123
> svn cat datei@30
456


Changelists
• Vorbild sind „tags“ von Gmail, Flickr und YouTube
• Seit Version 1.5
• Operationen
• Erzeugen mit
• svn changelist NAME PFAD1 PFAD2 ...
• Entfernen
• svn changelist NAME --remove PFAD

• Changelists können als Filter dienen
• svn commit --changelist NAME


Netzwerk
• Bei Verbindung
• Server schickt „Gruss“ mit Fähigkeiten/Protokollen
• Client antwortet mit Fähigkeiten/Protokollen

• Erst wenn Authentisierung notwendig ist
• Identifikation über Challenge-Response
• Vom Server initiiert
• Daten werden bei Commits als Author benutzt

• Anschliessend, falls konfiguriert
• Berechtigungskontrolle


Unterschiede zu CVS
• Addressierung
• P:L.T vs. P:T.L
• Folgen
• Versionierung der Inhalte der einzelnen Dateien
• unabhängig voneinander
• Versionsnummer bezieht sich auf das gesamte Archiv
• Löschen und Umbenennen bei CVS
• Nur leere Verzeichnisse
• Keine Kopien (komplett neue Datei)
• Umbennen/Verschieben: Kopie anlegen und alte löschen
• Immer mit Verlust der Historie


Unterschiede zu CVS
• Tagging und Branching
• Ist bei CVS gesondertes Konzept
• Nicht so einfach

• SVN: erkennt Binärdaten weitestgehend automatisch

• Verwechslungsgefahr
• cvs update entspricht svn status
• svn update holt Dateien vom Repository


Language-Bindings
• Benutzung von Subversion in anderen Programmen

• Ant SVNAnt
• C++ SVNCPP
• C# SubversionSharp
• Java SVNKit (pure Java)
• Maven Maven SCM Plugin
• .Net 2.0 SharpSvn
• Perl
• PHP PECL SVN
• Python PySVN
• Ruby


Benutzung mit Ant
• Möglichkeiten
• SvnAnt
• SvnKit
• Pfad mit Jar-Dateien aus SvnAnt und Task definieren
<path id="svn.path">
<ﬁleset dir="${lib.dir}"/>
</path>
<typedef resource="org/tigris/subversion/svnant/svnantlib.xml"
classpathref="svn.path" />
• Aufruf geschieht mit <svn>-Task
<svn username="harry" password="***">
<checkout url="svn://host/trunk" destPath="dir"/>
</svn>

Benutzung mit Ant
• Der <svn>-Task kennt die folgenden Attribute
• username, password
• javahl, javasvn
• dateFormatter, dateTimeZone
• failonerror
• Es gibt die folgenden Subtasks
• <add>, <cat>, <checkout>, <commit>
• <copy>, <createRepository>, <delete>, <diff>
• <export>, <ignore>, <import>, <info>,
<keywordsset>
• <keywordsadd>, <keywordsremove>, <move>
• <mkdir>, <propdel>, <propget>, <propset>, <revert>
• <status>, <switch>, <update>, <wcVersion>


Kritikpunkte an Subversion
• Kritik am Client-Server-Modell
• Zugriff zum Repository (Netzwerk) nötig
• Commit
• Branching / Tagging / Merging
• Arbeitskopie benutzt doppelten Speicherplatz
• Umlautprobleme zwischen Windows - Mac OS X - Unix
• Nur für Version 1.4, in Version 1.5 behoben
• Merging nicht History-aware
• Manuelles Notieren von Revisionsnummern
• Teilen von Arbeitsergebnissen zwischen zwei Entwicklern
ohne COMMIT nicht möglich


Installation und Konﬁguration


Konﬁguration für Benutzer
• Konfiguration für jeden User
• $HOME/.subversion unter Unix
• Anwendungsdaten/Subversion unter Windows
• auth
• Verzeichnis mit gespeicherten Authentisierungsdaten
• config
• Editor, Diff, Zeichensätze, etc
• servers
• Server und Zugriff auf diese


Installation des Servers
• Download von http://subversion.tigris.org
• Binärpackete für alle gängigen Plattformen
• Entpacken bzw. Aufrufen
• Sourcen
• subversion-1.5.0.tar.bz2
• subversion-deps-1.5.0.tar.bz2 [oft optional]
• Kompilieren
• $ tar xjf subversion-1.5.0.tar.bz2
• $ cd subversion-1.5.0
• $ ./conﬁgure --preﬁx=/opt/local
• $ make
• $ make check
• $ make install


Anlegen von Repositories
• Grundsätzliche Fragen
• Anzahl der Repositories
• Ein Repository für alle Projekte?
•Vorteil: Einfache Wartung
•Commit-Notifications, Triggers, Events
• Jedem Projekt ein eigenes Repository ?
•Vorteil: klare Struktur für Benutzer
• Zugriff?
• Protokoll?, Email?, Firewall?
• Struktur des Repositories
• Globales trunk, branches, tags
• Oder per Projekt?


• Zwei Arten von Repositories
• Berkeley DB (BDB)
• Inzwischen leicht veraltet
• Daten werden in Datenbank gespeichert
• Bei Abstürzen wird Administrator benötigt
• FSFS
• Daten werden im Dateisystem gespeichert
• Default seit Version 1.2
• Wird am meisten benutzt
• Ein wenig flexibler

• Daher: FSFS !


• Anlegen mit
• $ svnadmin create repositories/test1

• Unterverzeichnisse
• conf
• User, Passwörter
• db
• Das FSFS-Repository
• hooks
• „Customizing“
• locks
• Sperren


Zwei verschiedene Server
• svnserve
• svnserve + SASL
• Integration mit LDAP, Active Directory etc.
• svnserve + SSH [ + SASL ]
• Apache 2
• Integration mit LDAP, Active Directory etc.
• Komfortables Logging
• Proxy-Mechanismen für Lese-Zugriffe
• Benutzung von Apache2-Erweiterungen
• LDAP (Open LDAP)


Vor- und Nachteile der Server
• svnserve
• + Leichtgewichtig, „quick and easy“
• + Keine Benutzerkonten einzurichten
• - Kein Logging
• - Nur eine Authentisierungsmethode
• - keine Verschlüsselung
• svnserve mit SSH
• + Existierende SSH-Benutzerkonten
• + Verschlüsselt
• Apache HTTP Server
• + Vielseitig konfigurierbar
• - Langsamer als svnserve

Konﬁgurationsoptionen
• Verschlüsselung
• svnserver
• CRAM-MD5
• Cyrus-SASL-Support
• Nicht bei allen Distributionen
• Authentisierung
• SSL-Zertifikate
• Authorisierung / Zugangskontrolle
• Für das gesamte Repository
• Pfadbasiert
• Lese- und Schreibrechte pro Verzeichnis


Konﬁguration von svnserv
• Eigenständiger Dämon
• svnserve -d -r $HOME/subversion/repositories

• Integriert in inetd
• Eintrag in /etc/services
• Eintrag in /etc/inetd.conf
• svn stream tcp nowait svn /usr/bin/svnserve svnserve -i ...

• SSH-Tunneling
• SSH/RSH ruft temporären svnserve auf
• svnserve -t


Konﬁguration in conf (einfach)
• svnserv.conf
• [general]
password-db = passwd
realm = Test Repository 1
anon-access = none
auth-access = write
• password-db Datei mit Benutzern und Passwörtern
• realm Realm / Domäne
• anon-access Rechte für anonyme Benutzer
• read, write, none
• auth-access Rechte für eingeloggte Benutzer
• read, write, none


Konﬁguration in conf (einfach)
• Paare von Benutzern und Passwörtern mit passwd
[users]
harry = harryssecret
sally = sallyssecret

• Pfad-und Rechtedefinitionen mit authz-db
authz-db = DATEINAME

• Später mehr hierzu ...


Zugriffskontrolle mit SASL
• Seit Version 1.5
• Unterstützung von Cyrus SASL
• Nur, wenn Server und Client dieses unterstützen
• In svnserv.conf
• Abschnitt sasl
• use-sasl Soll SASL benutzt werden ?
• min-encryption Minimale Schlüssellänge
• max-encryption Maximale Schlüssellänge
• 1 für Checksummen
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256


Konﬁguration mit Apache 2
• Benötigt
• Apache 2, nicht 1.3
• mod_dav-Modul (von Apache 2)
• mod_dav_svn Backend (von Subversion)
• Und natürlich Subversion

• Entweder müssen die Binärpackete diese enthalten oder
man muss beim Kompilieren des Sourcecodes darauf
achten

• Apache2-Erfahrung ist ein Muss
• Ein wenig „tricky“


Laden der Module
• Zentrale Konfigurationsdatei von Apache 2
• httpd.conf
• Ergänzende Einträge
• <Location /svn>
• DAV svn
• # SVNPath /pfad/zum/repository
• SVNParentPath /pfad/zum
• </Location>
• Laden des Moduls für DAV (falls dynamisch gelinkt)
• LoadModule dav_module modules/mod_dav.so
• Laden des Moduls für Subversion
• LoadModule dav_svn_module modules/mod_dav_svn.so
• Sicherzustellen ist
• ServerName oder NameVirtualHost gesetzt

Authentisierung über HTTP
• Verwalten der Benutzerinformationen mit
• htpasswd -cm /etc/svn-secrets USERNAME
• Ergänzung der httpd.conf
• <Location /svn>
• DAV svn
• AuthType Basic
• AuthName „Repository“
• AuthUserFile /etc/svn-secrets
• Require valid-user
• </Location>
• Dieses ist für alle Requests
• Passwörter werden unverschlüsselt übertragen


Authentisierung über HTTP und SSL
• Alternative
• Übertragung von verschlüsselten Passwörtern
• AuthType Digest
• AuthDigestDomain /svn/
• Nachteil:
• Client und Server müssen die Passwörter bekannt sein
• Besser:
• SSL
• Subversion muss damit kompiliert worden sein
• Siehe Apache 2-Handbücher
• Jenseits dieses Vortrags


Authorisierung
• Für alle Benutzer und jeden Zugriff

• Einschränkung der Zugriffsart
• <LimitExcept GET PROPFIND OPTIONS REPORT>
• </LimitExcept>

• Viele weitere mehr möglich
• Siehe Apache 2-Handbücher


Pfadbasierte-Authorisierung
• Feinere Unterteilung ist möglich
• mod_authz_svn
• Dieses muss ebenfalls geladen werden
• LoadModule authz_svn_module modules/mod_authz_svn.so
• Dieses
• <Location /svn>
• DAV svn
• AuthzSVNAccessFile /pfad/zur/datei
• Satisfy Any
• </Location>
• Achtung: Kann sehr rechenintensiv werden
• SVNPathAuthz off


Pfadbasierte Rechtevergabe
• Rechtevergabe auf Basis von Pfaden
• Gleiche Syntax bei Apache 2 und Subversion

• Frage:
• Wird die wirklich benötigt?
• Sind getrennte Repositories einfacher zu managen?
• Administrationsaufwand ist hoch

• Syntax für Pfadberechtigungen

• [test1:/branches]
• harry = rw
• sally = r


• Allgemeine Syntax
• [REPOSITORY:PFAD]
• USER = RW
• Überschreiben ist möglich (Vererbung)
• [test1:/branches/V1.0]
• harry =
• Harry hat keinen Zugriff auf die Version 1.0
• Die Rechte der genausten Pfadangabe werden benutzt
• [test1:/]
• *=r
• Alle Benutzer können test1 lesen


• Bildung von Gruppen von Benutzern
• [groups]
• entwickler = harry, sally
• alle = @entwickler, johny

• Gruppen können Gruppen enthalten

• Gruppen können bei der Rechtevergabe benutzt werden

• [test1:/pfad/datei]
• @entwickler = rw


Konﬁguration mit hooks
• Hier können selbstgeschriebene Skripte aufgerufen
werden
• start-commit
• pre-commit
• post-commit
• pre-revprop-change
• post-revprop-change
• pre-lock
• post-lock
• pre-unlock
• post-unlock
• Ist nur Fortgeschrittenen zu empfehlen
• Wird meistens nicht benötigt

Referenzen


Bücher (Auswahl)
• C. Michael Pilato, Ben Collins-Sussman,
Brian W. Fitzpatrick. Version Control with
Subversion. O‘Reilly. 2002.
• Open-Source-Buch
• http://svnbook.red-bean.com

• Jeffrey Machols. Subversion in Action.
Manning. 2004.

• Mike Mason. Pragmatic Version Control
using Subversion. Pragmatic Programmers,
LLC. 2005.


Webseiten
Hauptseite http://subversion.tigris.org

Subversion CollabNet http://www.collab.net/

Buch http://svnbook.red-bean.com

TortoiseSVN http://tortoisesvn.tigris.org/
Desktop
Integration SCPlugin http://scplugin.tigris.org/

RapidSVN Admin http://rapidsvn.tigris.org/
Clients
WebSVN http://websvn.tigris.org/

Konvertierung cvs2svn http://cvs2svn.tigris.org/

Subclipse http://subclipse.tigris.org/
Eclipse
Subversive http://www.eclipse.org/subversive/

SVNAnt Ant Tasks http://subclipse.tigris.org/svnant.html

Java Pure Java http://svnkit.com/
SVNKit
Entwicklung Bibliothek
Maven http://maven.apache.org/scm/plugins/index.html

Subversion http://svk.bestpractical.com/view/HomePage
SVK
Erweiterungen
Bazaar http://bazaar-vcs.org/

Darcs http://www.darcs.net/
Verteilte http://git.or.cz/
Git
Systeme
Mercurial http://www.selenic.com/mercurial/wiki/

Monotone http://www.monotone.ca/


Subversion Schulung

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Subversion Schulung

Ähnlich wie Subversion Schulung (20)

Mehr von Jörn Dinkla

Mehr von Jörn Dinkla (16)

Subversion Schulung

Hinweis der Redaktion