SUBVERSION - DER NACHFOLGER FÜR CVS

Transkript

1 SUBVERSION - DER NACHFOLGER FÜR CVS Ersteller: Thomas Weber Datum: 16. Februar 2005 Version: Trivadis AG

2 INHALTSVERZEICHNIS Motivation...2 Wie alles begann...2 Charakteristik...3 Architektur...3 Überblick...3 Repository Format...4 Netzwerk...5 Zugriffsarten...5 Server...6 Clients...7 Arbeitsweise...9 Subversion bei Trivadis...11 Motivation Seit vielen Jahren ist CVS der Quasistandard bei der Versionsverwaltung von Dokumenten und Quelltexten. Vor allem im OpenSource Bereich hat er eine breite Akzeptanz und Verbreitung gefunden. Doch der Platzhirsch ist in die Jahre gekommen und seine Schwächen treten immer deutlicher zu Tage. Die Entwicklergemeinde hat reagiert und ein neues System für die Versionsverwaltung lanciert. Die Stärken von CVS übernehmen aber seine Schwachstellen besser machen, das war der hohe Anspruch, den sich der Newcomer selbst stellte. Das Ergebnis erschien im Sommer 2004 in der Version 1.0 und wird kontinuierlich weiterentwickelt. Wie alles begann Im Jahre 2000 entschied sich die Firma CollabNet, die Entwicklung eines Ersatzes für CVS voranzutreiben. Ziel war es, die eigene Collaboration Software Suite SourceCast zu verbessern. SourceCast verwendete bis anhin CVS zur Versionskontrolle. Auf der Suche nach geeigneten Entwicklern für dieses Unterfangen begegnete man Karl Fogel, dem Autor von Open Source Development with CVS und Jim Blandy. Beide diskutierten selbst bereits schon seit einiger Zeit über das Design einer neuen Versionsverwaltung. Zusammen mit Ben Collins-Sussman, Brian Behlendorf and Jason Robbins von CollabNet sowie Greg Stein als Freelancer begann die Entwicklung von Subversion. Am 31. August 2001, nach nur 14 Monaten Entwicklungsarbeit, löste Subversion das betagte CVS für die eigene Versionsverwaltung ab. Subversion wurde selfhosting. Noch heute beschäftigt CollabNet eine Reihe von Vollzeitentwicklern für Subversion. Daneben hat sich aber auch eine grosse OpenSource Gemeinde gebildet und die Entwicklung in die Breite getragen. CollabNet's Copyright Lizenz ist vollständig in Übereinstimmung mit den Debian Free Software Guidelines. Subversion_Art.doc 2 /

3 Charakteristik Subversion ist eine OpenSource basierte Versionsverwaltung, die mit dem Ziel CVS abzulösen komplett neu geschrieben wurde. Dadurch unterscheidet es sich in den folgenden Punkten von CVS: Verzeichnisversionierung: Subversion verwaltet intern ein virtuell versioniertes Filesystem. Dadurch können Änderungen von Files und kompletten Verzeichnissen verfolgt werden. Selbst symbolische Links unter Unix werden verwaltet. Hinzufügen, Umbenennen, Verschieben und Löschen von Dateien und Verzeichnissen sind somit möglich. Echte atomare Commits: Die Transaktionssicherheit beim Einchecken von Daten war ein wichtiges Designziel. Subversion sorgt dafür, dass entweder alle Änderungen im Repository landen oder keine. Versionierung von Metadaten: Jedes File oder Verzeichnis kann beliebige Eigenschaftswerte besitzen. Diese Metadaten werden ebenfalls versioniert. Auswahl an Repository-Schnittstellen: Die Schnittstelle zum Repositoryzugriff ist abstrahiert. Somit können beliebige neue Wege für den Netzwerkzugriff implementiert werden. Bis dato werden ein proprietärer Server und ein WebDAV-Modul für den Apache mitgeliefert. Letzteres ermöglicht den flexiblen Zugriff über HTTP(S) und bindet die zahlreichen Authentisierungsmöglichkeiten des Apache Webservers ein. Daneben ist ebenso der direkte lokale Repositoryzugriff möglich. Konsistente Datenbehandlung: Der binäre Differenzierungsalgorithmus ist einheitlich für Text- und Binärdaten. Alle Datentypen werden im gleichen Format komprimiert und gespeichert. Die Diffs werden in beiden Richtungen über das Netzwerk geschickt. Das ist möglich, weil die letzte ausgecheckte Version immer lokal gespeichert wird. Effizientes und ressourcenschonendes Branching und Tagging: Das Erstellen von Entwicklungszweigen und Releases erfolgt durch einen Kopiermechanismus, der ähnlich den Hardlinks arbeitet. Dadurch werden cheap copies erzeugt. Erweiterter Befehlssatz: Subversion verfügt über folgende zusätzliche Kommandos: copy, move, merge, resolved, mkdir, propset, propget, proplist, propdel, propedit, revert, switch, info, cat, list Architektur Überblick Subversion wurde von Beginn an als klassisches Client/Server Modell konzipiert. Der Code ist modular strukturiert und es gibt klar definierte Schnittstellen auf Subversion_Art.doc 3 /

4 allen Ebenen, welche von Applikationen verwendet werden können. Somit ist Subversion jederzeit durch neue Repository Formate, Servertypen oder Clients erweiterbar. Abbildung 1: Gesamtarchitektur Repository Format Eine wesentliche Neuerung zu CVS besteht darin, dass das Repository in einer Datenbank gespeichert werden kann. Subversion verwendet dafür die OpenSource Lösung Berkeley-DB. Ab der Version 1.1 von Subversion kann auch das Filesystem-Repository FSFS verwendet werden. Die besonderen Vorteile dieses Formats liegen in: Einfaches Kopieren der Repositories möglich (plattformunabhängiges Format) Repository kann auf Netzwerklaufwerk liegen (share) Standardbackuptools einsetzbar Skalierbar (Verlinken von alten Revisions auf andere Laufwerke, sollte das Repository voll sein) Subversion_Art.doc 4 /

5 Netzwerk Neben der Client/Server Architektur war die Verwendung von Subversion im Netzwerk ein weiteres wesentliches Designziel. Vom ersten Tag an war die Unterstützung des WebDAV/DeltaV Protokolls vorgesehen. Das schon allein durch die Anwesenheit von Greg Stein, der aktiv am WebDAV/DeltaV Spezifikationsprozess mitarbeitete. Das proprietäre svn-protokoll kam erst viel später hinzu, um auch einen einfachen Servertyp bereitstellen zu können. In den lokalen Verzeichnissen der Projekte legt Subversion spezielle Unterverzeichnisse (.svn) für administrative Zwecke an. In diesen Verzeichnissen finden sich anders als bei CVS exakte Kopien der Projektdateien mit dem Stand des letzten Checkouts oder Commits. Es ist bei Subversion daher nicht mehr erforderlich, den aktuellen stand einer Datei im Repository abzufragen. Stattdessen kann der Subversion-Client einfach die pristine copy (unberührte Kopie) im.svn Verzeichnis für den Vergleich heranziehen. Durch diese Arbeitsweise kann nicht nur die Netzlast erheblich reduziert werden, man kommt so für viele Funktionen ganz ohne Netzwerkverbindungen aus und ist daher wesentlich mobiler z.b. mit einem Laptop. Zugriffsarten Sämtliche Zugriffe auf das Repository werden über URLs adressiert. Abbildung 2: Zugriffsarten Diese Standardsyntax für die Repositoryadresse ermöglicht einen einheitlichen Zugriffspfad unabhängig vom verwendeten Servertyp. Der file: Zugriff ist dabei immer nur lokal möglich. $ svn checkout file:///path/to/repos $ svn checkout file://localhost/path/to/repos Für den entfernten Zugriff auf das Repository steht neben dem HTTP-Protokoll auch das proprietäre SVN-Protokoll zur Verfügung. Dabei können die Verbindungen automatisch über einen SSH-Tunnel Verschlüsselt werden: $ svn list svn+ssh://host.example.com/repos/project Subversion_Art.doc 5 /

6 Bei einer SSL Verbindung kann die Authentisierung ausserdem anhand eines Clientzertifikates erfolgen: $ svn list Authentication realm: Client certificate filename: /path/to/my/cert.p12 Passphrase for '/path/to/my/cert.p12': ******** Server In der Softwaredistribution von Subversion sind der proprietäre SVNServe Server sowie das Apache Modul mod_dav_svn enthalten. Während der Entwicklung von Subversion war der Repositoryzugriff über den Apache Webserver als primärer Weg geplant, SVNServe kam erst später hinzu, um einen leicht installierbare Alternative zu haben. SVNServe Hierbei handelt es sich um einen leichtgewichtigen Server, der das TCP/IP basiertes Protokoll svn verwendet. Der Port für den Zugriff auf den Server kann beliebig definiert werden. Die IANA hat jedoch offiziell Port 3690 für das Subversion Protokoll reserviert. SVNServe kann per Inetd, als Daemon (Service) oder manuell gestartet werden. Im tunnel mode lassen sich die Verbindungen zum Server mittels RSH oder SSH absicheren. Beispiel: svn://host.example.com/project1 svn+ssh://host.example.com/project1 (Secure Shell) Apache Modul mod_dav_svn Mit dem Apache Webserver als Basis für den Repositoryzugriff eröffnen sich dem Anwender zahlreiche Möglichkeiten hinsichtlich der Authentisierung und Autorisierung. Dazu bietet der Apache selbst bereits die verschiedensten Mechanismen an, welche dann auch von Subversion verwendet werden können: Per-Directory Access Control Basic HTTP Authentication SSL Certificate Authentication LDAP Directory Authentication Der Zugriff auf das Repository über den Apache bietet mehr Funktionen als der SVNServe, jedoch ist die Installation und Konfiguration dieses Servers komplexer: Subversion_Art.doc 6 /

7 LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so Das Modul mod_dav erweitert das HTTP-Protokoll um die Möglichkeit en von Schreibzugriffen, mod_dav_svn verwendet darüber hinaus die Subversion- Libraries, um das Repository Format lesen und schreiben zu können. Mit dem Modul mod_authz_svn kann eine feingranulare Zugriffsberechtigungsvorschrift etabliert werden: <Location /repos> DAV svn SVNParentPath /usr/local/svn # Definition der Zugriffsberechtigungen AuthzSVNAccessFile /path/to/access/file # zuerst anonymen Zugriff versuchen, falls # notwendig authentisieren Satisfy Any Require valid-user # Wie wird der User authentisiert AuthType Basic AuthName "Subversion repository" AuthUserFile /path/to/users/file </Location> Clients Innerhalb der Subversion-Distribution ist ein Kommandozeilenclient enthalten. Daneben gibt es aber noch zahlreiche weitere Clients und Plugins für nahezu jede verfügbare IDE wie z.b.: AnkhSVN ( Subversion add-in für Microsoft Visual Studio.NET JSVN ( Java Subversion Client, einschliesslich Plugin für IDEA psvn.el ( Subversion Interface für Emacs RapidSVN ( Cross-platform Subversion GUI, basiert auf WxPython libraries Subversion_Art.doc 7 /

8 Abbildung 3: RapidSVN Subclipse ( Subversion Plugin für die Eclipse Umgebung Subway ( Microsoft SCC Provider für Subversion sourcecross.org ( Microsoft SCC Provider für Subversion Supervision ( Java/Swing visual Client für Subversion Sven ( Native GUI für Subversion unter Verwendung des Mac OS X Cocoa Frameworks Svn4Eclipse ( Subversion Plugin für die Eclipse IDE Svn-Up ( Java-basiertes GUI für Subversion und Plugin für die IDEA IDE TortoiseSVN ( Microsoft Windows Explorer Extension Subversion_Art.doc 8 /

9 Abbildung 4: TortoiseSVN WorkBench ( Cross platform Python-based software development GUI built on Subversion viele weitere Clients Auf Windowsplattformen ist besonders der TortoiseSVN Client als Erweiterung des Windows Explorers interessant. RapidSVN dagegen ist eine, auf vielen Plattformen verfügbare, graphische Oberfläche. Bei Verwendung des Apache Modules mod_dav_svn sollte prinzipiell jeder WebDAV Client in der Lage sein, auf das Repository zuzugreifen. Arbeitsweise Wie CVS auch arbeitet Subversion nach dem copy-modify-merge Versionierungsmodell. Im Gegensatz zum lock-modify-unlock Modell können dabei beliebig viele Entwickler gleichzeitig an dem selben Sourcecode arbeiten. Eventuell auftretende Konflikte werden dann erst beim Einchecken der Änderungen geprüft und gelöst. Dieses Modell verhindert, dass Quelltexte versehentlich oder durch Abwesenheit blockiert werden oder dass zwei Entwickler nicht gleichzeitig an völlig verschiedenen Stellen im Quelltext arbeiten können. Subversion_Art.doc 9 /

10 Mit dem copy-modify-merge Modell ergibt sich für jedes Subversion Projekt eine einfache Vier-Schritt Arbeitsweise: 1. Checkout einer Arbeitskopie aus dem Repository auf die lokale Festplatte 2. Änderungen an den Quelltexten vornehmen 3. Auf potentielle Änderungen der Dateien im Repository prüfen (update) und gegebenenfalls mit der lokalen Version mergen 4. Commit der eigenen Änderungen ins Repository Konflikte könne durch den Befehl merge automatisch gelöst werden, falls die Änderungen unterschiedliche Stellen im Quelltext betreffen. Andernfalls ist eine Konfliktlösung nur manuell durch menschliche Intelligenz möglich. Mit der Version 1.2 von Subversion wird auch das lock-modify-unlock Versionierungsmodell als zusätzliche Option unterstützt. Es ist jedem Entwickler freigestellt, welches Repository Layout er für sein Projekt verwenden möchte. Die Subversion Community empfiehlt folgende einheitliche Struktur mit drei Unterverzeichnissen für jedes Projekt: trunk/ source/ docs/ buildtools/ branches/ issue-1003/ issue-1004/ tags/ alpha-1/ 1.0.0/ 1.0.1/ Dabei enthält das Verzeichnis trunk den aktiven Hauptast des Entwicklungspfades des Projektes. In branches können parallele Entwicklungszweige eröffnet und später mit dem Hauptast wieder vereint werden. Das Verzeichnis tags enthält die offiziellen Releases des Hauptentwicklungsastes. Für Branches und Tags werden dabei mittels des Cheap-Kopie-Konzeptes nur die Änderungen in diese Verzeichnisse geschrieben. Einmal erstellte Tags (Release) sind dabei selbstverständlich nicht mehr überschreibbar während in Branches genau wie in Trunk gearbeitet werden kann. Subversion_Art.doc 10 /

11 Subversion bei Trivadis Seit kurzer Zeit ist Subversion bei Trivadis im produktiven Einsatz und ersetzt das bis dahin vorherrschende CVS. Ein wesentlicher Grund für den Entscheid zugunsten dieser Lösung war die Möglichkeit, auch ausserhalb des Trivadis-Netzes durch das HTTPS Protokoll direkt auf das Repository zugreifen zu können. Dieser Aspekt ist für viele Consultants, die vorrangig bei Kunden im Einsatz sind, besonders wichtig. Es stellt sicher, dass man von nahezu überall her Sourcecode ein- und auschecken kann. Die Sicherheit konnte dabei auf dem gleichen Niveau gehalten werden, wie es für den gesamten Intranetzugriff bei Trivadis praktiziert wird. In den nächsten Monaten steht nun die Migration von über 130 CVS Projekten nach Subversion an. Das Migrationsteam wird dabei zusammen mit den Projektleitern Schritt für Schritt die Repositories konvertieren. Als Ziel ist gesetzt, dass alle Revisionen fehlerfrei in Subversion importiert werden können. Subversion_Art.doc 11 /