Más contenido relacionado
La actualidad más candente (20)
Similar a Subversion Schulung (20)
Subversion Schulung
- 1. 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
- 2. 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
- 4. Überblick
• Versionsverwaltung
• Subversion
• Grundlagen
• Praxis
• Benutzung bei typischen Arbeitsschritten
• Fortgeschrittene Praxis
• Installation und Konfiguration
• Zwischendurch
• Hands-on
• Gemeinsam benutzen, installieren, konfigurieren
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 4
- 6. Versionsverwaltungen
• Ähnlichkeit zu einem Fileserver oder Dateisystem
• Aber: zusätzlich die zeitliche Dimension
• Ein Dateisystem mit Gedächtnis
• „persistente“ Datenstruktur [CLR90]
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 6
- 7. Versionsverwaltung
• Unterschiedliche Namen
• Revision Control System
• Version Control System (VCS)
• Source Code Management (SCM)
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 7
- 8. 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“
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 8
- 9. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 9
- 10. Repository-Modell
• Zentral
• Client-Server
• Repository auf dem Server
• Auf dem Client nur Arbeitskopien
Repositor
Commit Checkout
Update
User A User B User C
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 10
- 11. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 11
- 12. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 12
- 13. Kontrollierte Zugriff
• Mehrere Benutzer
• Gleichzeitige Änderungen ?
• Überschreiben von Informationen ?
• Kontrolle
• Zugriff
• Locks / Sperren
• lock-modify-unlock
• Änderungen
• Konflikte
• copy-modify-merge
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 13
- 14. Zugriff: Lock-Modify-Unlock
• Vor dem Bearbeiten
• Sperren
• Nach dem Bearbeiten
• Entsperren
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 14
- 15. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 15
- 18. Zugriff: Copy-Modify-Merge
• 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.
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 18
- 19. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 19
- 20. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 20
- 21. Neue Entwicklungen
• SVK
• Ergänzung zu Subversion
• Verteilte Systeme
• Bazaar
• Mercurial
• Git
• Monotone
• Darcs
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 21
- 23. Architektur von Subversion
• GUI
• Client
• Netzwerk
• Server
• Repository
• Speicher
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 23
- 24. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 24
- 25. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 25
- 26. 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/
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 26
- 27. 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.
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 27
- 28. Clients: GUI
• Auswahl: RapidSVN und Eclipse
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 28
- 29. Clients: WebSVN
• Zugriff mit WebSVN
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 29
- 30. 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
svndumpfilter Administration, Dumps von
Repositories
svnversion Gibt die Revisionsnummern an
mod_dav_svn Plugin für den Apache HTTP-Server
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 30
- 31. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 31
- 32. Repositories und URLs
• Abbildung zwischen URL und Dateien im Repository
• svn://localhost/test1/trunk/beispiel-java/build.xml
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 32
- 33. 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/
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 33
- 34. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 34
- 35. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 35
- 36. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 36
- 37. 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 Konflikte lösen
geändert
Commit
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 37
- 38. Arbeitskopie: Zustände
• Ausgabe von svn status -u
? scratch.c
A stuff/loot/bloo.h
C stuff/loot/lump.c
D stuff/fish.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“
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 38
- 39. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 39
- 40. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 40
- 41. Konflikte 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);
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 41
- 42. Konflikte lösen
• Bei einem Konflikt gibt es die folgenden Möglichkeiten
• Aufschieben
• Version aus Arbeitskopie übernehmen
• Version aus Repository übernehmen
• Dateien ineinanderführen, „mergen“
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 42
- 43. Konflikte 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 43
- 44. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 44
- 45. Weitere Arbeitsschritte
• Anlegen
• einer Marke, „tag“
• eines Zweiges, „branch“
• eines neuen Projekts
• Zusammenführen von Zweigen, „merge“
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 45
- 46. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 46
- 47. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 47
- 48. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 48
- 49. 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“
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 49
- 50. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 50
- 51. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 51
- 52. Zusammenführen / Mergen
• 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 52
- 53. Zusammenführen / Mergen
• 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 53
- 54. Zusammenführen / Mergen
• 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 54
- 55. Zusammenführen / Mergen
• 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 55
- 56. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 56
- 58. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 58
- 59. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 59
- 60. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 60
- 61. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 61
- 62. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 62
- 63. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 63
- 64. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 64
- 65. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 65
- 66. Externe Definitionen
• 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 66
- 67. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 67
- 68. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 68
- 69. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 69
- 70. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 70
- 71. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 71
- 72. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 72
- 73. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 73
- 74. Benutzung mit Ant
• Möglichkeiten
• SvnAnt
• SvnKit
• Pfad mit Jar-Dateien aus SvnAnt und Task definieren
<path id="svn.path">
<fileset 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>
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 74
- 75. 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>
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 75
- 76. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 76
- 78. Konfiguration 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 78
- 79. 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
• $ ./configure --prefix=/opt/local
• $ make
• $ make check
• $ make install
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 79
- 80. 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?
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 80
- 81. Anlegen von Repositories
• 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 !
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 81
- 82. Anlegen von Repositories
• Anlegen mit
• $ svnadmin create repositories/test1
• Unterverzeichnisse
• conf
• User, Passwörter
• db
• Das FSFS-Repository
• hooks
• „Customizing“
• locks
• Sperren
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 82
- 83. 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)
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 83
- 84. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 84
- 85. Konfigurationsoptionen
• 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 85
- 86. Konfiguration 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 86
- 87. Konfiguration 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 87
- 88. Konfiguration 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 ...
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 88
- 89. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 89
- 90. Konfiguration 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“
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 90
- 91. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 91
- 92. Authentisierung über HTTP
• Verwalten der Benutzerinformationen mit
• htpasswd -cm /etc/svn-secrets USERNAME
• Ergänzung der httpd.conf
• <Location /svn>
• DAV svn
• SVNParentPath /pfad/zum
• AuthType Basic
• AuthName „Repository“
• AuthUserFile /etc/svn-secrets
• Require valid-user
• </Location>
• Dieses ist für alle Requests
• Passwörter werden unverschlüsselt übertragen
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 92
- 93. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 93
- 94. Authorisierung
• Für alle Benutzer und jeden Zugriff
• Require valid-user
• Einschränkung der Zugriffsart
• <LimitExcept GET PROPFIND OPTIONS REPORT>
• Require valid-user
• </LimitExcept>
• Viele weitere mehr möglich
• Siehe Apache 2-Handbücher
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 94
- 95. 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
• SVNParentPath /pfad/zum
• AuthzSVNAccessFile /pfad/zur/datei
• Satisfy Any
• Require valid-user
• </Location>
• Achtung: Kann sehr rechenintensiv werden
• SVNPathAuthz off
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 95
- 96. 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 96
- 97. Pfadbasierte Rechtevergabe
• 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 97
- 98. Pfadbasierte Rechtevergabe
• 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 98
- 99. Konfiguration 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
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 99
- 101. 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.
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 101
- 102. 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/
© 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 102
Notas del editor
- TODO SVNKit
- TODO
- TODO cvs2svn