Subversion Schulung

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    Notes on slide 1

    TODO SVNKit

    TODO

    TODO cvs2svn

    Favorites, Groups & Events

    Subversion Schulung - Presentation 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

    + Jörn DinklaJörn Dinkla, 2 months ago

    custom

    392 views, 0 favs, 0 embeds more stats

    Einführung in die Versionskontrolle mit Subversion more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 392
      • 392 on SlideShare
      • 0 from embeds
    • Comments 0
    • Favorites 0
    • Downloads 2
    Most viewed embeds

    more

    All embeds

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories