Versionsmanagement mit Subversion Einführung + Demo Lehrstuhl Softwaretechnik Softwarepraktikum 2005 Nicolas Gümbel
Motivation Mitglieder einer Software Entwicklungsgruppe müssen: gemeinsamen Zugriff auf die Projektressourcen haben => File Sharing gleichzeitig identische Ressourcen bearbeiten können => Concurrent Editing die Projekt-Historie der Ressourcen verfolgen können => File History Ein Versionsmanagement-System liefert hier geeignete Software Mechanismen, um File Sharing, Concurrent Editing und File History zu ermöglichen.
Warum ist Concurrent Editing schwierig? Ein normaler File Server (z.b. NFS) kann File Sharing erleichtern, aber er kann immer nur die aktuelle Version der Datei speichern.
Lock-Modify-Unlock Ein einfacher Mechanismus zur Concurrent Editing Unterstützung:
Lock-Modify-Unlock Nachteile dieses Ansatzes: Delays: Datei-Locking verhindert Concurrent Editing Administrative Overhead: Falls ein Entwickler vergisst ein Datei-Locking freizugeben, dann muss dieser Lock explizit vom Administrator entfernt werden, bevor ein anderer Entwickler diese Datei neu editieren kann. False Sense of Security: Ein Datei-Lock einer einzelnen Datei A ist nicht ausreichend, wenn andere Dateien von Datei A implizit abhängig sind.
Copy-Modify-Merge I
Copy-Modify-Merge II
Copy-Modify-Merge III Zwei Möglichkeiten können beim Zusammenfügen (merge) der Datei auftreten. Changes that do not overlap: Trivial. Das Zusammenfügen kann automatisch passieren. Changes that overlap: In diesem Fall tritt ein Konflikt auf und das Zusammenfügen wird schwieriger. Die Entwickler müssen gemeinsam entscheiden, welche Version übernommen werden soll (Kommunikation notwendig!) Merging ist ein manueller Prozess der Entwickler. Kein Versionsmanagementsystem kann diesen Prozess abnehmen. Der Zeitbedarf, um diesen Konflikt zu lösen, ist wesentlich geringer als beim Lock- Modify-Unlock Ansatz.
Versionsmanagement-Systeme Viele Systeme mit unterschiedlichen Funktionen. RCS CVS Aegis Arch BitKeeper CMSynergy Co-Op Darcs Monotone Rational ClearCase OpenCM Perforce Subversion Superversion svk Vesta Visual SourceSafe Für das SoPra: Einsatz von Subversion
Subversion vs. Visual SourceSafe Atomare Commits Ja Subversion Nein Visual SourceSafe Umbenennen von Dateien und Verzeichnissen Dokumentation Webinterface Verfügbarkeit von GUI-Clients Netzwerkunterstützung Portabilität Lizenz Ja Viel Dokumentation vorhanden, u.a. ein frei verfügbares E-Book (welches im O Reilly-Verlag erschienen ist) Ja. ViewCVS, SVN::Web, WebSVN, ViewSVN, mod_svn_view, Chora, usw. Sehr gut, z.b. RapidSVN, SmartSVN, TortoiseSVN (Windows Explorer plug-in), AnkhSVN (Visual Studio Plugin), usw. Sehr gut. Verwendung offener Standards WebDAV+DeltaV welche auf HTTP/HTTPS aufbauen Client und Server für Unix, Windows und Mac OS X verfügbar Open-Source Indirekt (Workaround notwendig) Mittelmäßig. Hilfedatei verfügbar. Nein. Es gibt eine Standalone-GUI und ein SCCI Plugin für Visual Studio Über Windows Netzwerkfreigaben, schlechte Performance bei langsamer Netzwerkverbindung Windows Kommerzielles Produkt
Subversion's Architektur
Modell des kooperativen Entwickelns Einzelner Entwickler: Es kann durchaus sinnvoll sein ein Versionsmanagementsystem als einzelner Entwickler einzusetzen (Tags, Entwicklungszweige, Historie, Backup, ) Mehrere Entwickler: Quelltext wird geteilt: Team ist für Quelltext verantwortlich Entwickler arbeiten auf lokalen Arbeitskopien (working copies), niemals auf der Masterkopie Kontrolle über den Quelltext hat das Versionsmanagementsystem, nicht der Entwickler (Backup, Versionsstände, ) Quelltext-Distribution übernimmt das Versionsmanagementsystem
Entwicklungszyklen
Entwicklungszyklen
Revisionsnummern in Subversion Revisionsnummern in Subversion sind global (d.h. bezogen auf das ganze Repository) und nicht lokal (d.h. auf einzelne Dateien bezogen, wie z.b. in cvs). Die Revisionsnummer N repräsentiert also den Zustand des Repository s nach dem N ten commit. Wenn man über Revisionsnummer N einer Datei xy redet, meint man also die Version der Datei, die im Repository mit der Revisionsnummer N vorhanden war. Eine andere Version M der gleichen Datei muss also nicht unbedingt verschieden sein!
Weitere Tipps im Umgang mit Subversion Lieber öfters kleinere Änderungen einchecken Die Protokollfunktion von Subversion verwenden Immer nur Versionen einchecken, welche auch kompilierbar sind! Es gibt ein freies E-Book über Subversion, welches auch im O Reilly Verlag erschienen ist: http://svnbook.red-bean.com/ Zugangsdaten http://loewenheim.informatik.uni-augsburg.de/svn/gruppexy User (Nachname) & Passwort über die Tutorien! Subversion Clients http://ankhsvn.tigris.org/ (Visual Studio.NET Plugin) http://tortoisesvn.tigris.org/ (Explorer Shell Erweiterung) Achtung! Visual Studio.NET hat speziell bei Webanwendungen ein Problem mit Ordnern, deren Endung mit einem Punkt beginnt. Da Subversion in jeder lokalen Arbeitskopie Metadaten im Verzeichnis.svn abspeichert kommt es hier zum Problem. ankhsvn kann so konfiguriert werden, dass die Metadaten im Verzeichnis _svn gespeichert werden Von TortoiseSVN gibt es eine spezielle Version, welche _svn-ordner verwendet