Subversion Schulung

  • 4,679 views
Uploaded on

Einführung in die Versionskontrolle mit Subversion.

Einführung in die Versionskontrolle mit Subversion.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,679
On Slideshare
0
From Embeds
0
Number of Embeds
4

Actions

Shares
Downloads
2
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • TODO SVNKit
  • TODO
  • TODO cvs2svn

Transcript

  • 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
  • 3. Überblick © 2008 - 2009 Jörn Dinkla, http://www.dinkla.com
  • 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
  • 5. Versionsverwaltungen © 2008 - 2009 Jörn Dinkla, http://www.dinkla.com
  • 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
  • 16. Zugriff: Copy-Modify-Merge • Gleichzeitige Änderungen © 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 16
  • 17. Zugriff: Copy-Modify-Merge • Harry merged die Änderungen © 2008 - 2009 Jörn Dinkla, http://www.dinkla.com 17
  • 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
  • 22. Subversion © 2008 - 2009 Jörn Dinkla, http://www.dinkla.com
  • 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
  • 57. Fortgeschrittene Themen © 2008 - 2009 Jörn Dinkla, http://www.dinkla.com
  • 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
  • 77. Installation und Konfiguration © 2008 - 2009 Jörn Dinkla, http://www.dinkla.com
  • 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
  • 100. Referenzen © 2008 - 2009 Jörn Dinkla, http://www.dinkla.com
  • 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