Kategorisierung und Schnittstellenbeschreibung der Versionskontrolle bei Content Management Systemen

Transkript

1 Kategorisierung und Schnittstellenbeschreibung der Versionskontrolle bei Content Management Systemen Wollmann Tibor, Rödig Martin Augsburg University of Applied Sciences Dept. of Computer Science Baumgartnerstr Augsburg In diesem Papier soll die Verwendung der Versionskontrolle bei Content Management Systemen (CMS) untersucht und kategorisiert werden. Zu diesem Zweck werden sowohl die Anforderungen an die Versionskontrolle, als auch Schnittstellen zu CM-Systemen, wie WebDAV und DeltaV, betrachtet. Des weiteren soll aufgezeigt werden, wie sich das gängige Versionskotroll-System CVS in ein CM-System einbinden lässt und welche Probleme hierbei auftreten können. Einleitung Bei Softwareprojekten ist es notwendig, regelmäßig den Sourcecode zu sichern. Dies geschieht, um alte Zustände wieder herzustellen, Änderungen nachzuvollziehen oder bei einem Defekt der Speichermedien auf eine Kopie der aktuellen Daten zurück greifen zu können. So wie bei der Softwareentwicklung der Sourcecode verwaltet werden muss, sollte auch bei einem CM-System der Content sowie das Layout verwaltet werden. Die Anforderungen an eine Verwaltung in CM- Systemen sind jedoch höher. Zu den Verwaltungsfunktionen kommen auch Freischaltungsmechanismen und Linkkontrolle. Diese Arbeit untergliedert die Versionskontrolle in zwei Teilgebiete: die statische Versionskontrolle und die dynamische Versionskontrolle. Allerdings kann man bei der statischen Versionskontrolle nicht viel erwarten, da es sich eigentlich nur um eine Art Backupverfahren handelt. Die dynamische hingegen bietet eine Vielzahl von Möglichkeiten. Ein weiterer Aspekt bei der Versionskontrolle sind die Schnittstellen. Unter den verfügbaren Technologien bezieht sich diese Arbeit auf das Concurrent Versioning System (CVS), Web Distributed Authoring and Versioning (WebDAV) und DeltaV, die als offene Standards oder Protokolle zur Verfügung stehen. Obwohl CVS für die Verwaltung von Sourcecode gedacht ist, wird untersucht, inwiefern es für die Versionskontrolle in CM-Systemen geeignet ist. Die beiden Protokolle WebDAV und DeltaV definieren Methoden um Versionskontroll- Mechanismen über das Web allgemein zu standardisieren. Sie werden bereits in vielen Software- Produkten, wie Adobe Photoshop, Microsoft Office oder Macromedia Dreamweaver implementiert. Dies macht diese Protokolle für den Einsatz in CM-Systemen besonders attraktiv.

2 Statische Versionskontrolle Zur statischen Versionskontrolle von CM-Systemen zählen wir alle Systeme, die nur eine Art Backup-Mechanismus darstellen. Hierzu wird der gesamte Verzeichnisbaum zu einem bestimmten Zeitpunkt kopiert und in einem anderen Verzeichnis oder einem anderen Datenträger gesichert. Der Vorteil bei dieser Art der Versionskontrolle ist die Einfachheit. Es werden nur regelmäßige Backups des Projektes erstellt. Es ist jedoch notwendig, dass nur funktionstüchtige Versionen gespeichert werden, ansonsten wäre es möglich, dass bereits behobene Fehler nach der Einspielung einer älteren Version wieder auftreten. Da es bei mehreren Redakteuren und Entwicklern meistens nicht möglich ist gleichzeitig in allen Teilbereichen fehlerfreie Datenbestände zu erreichen, ist die statische Versionskontrolle unserer Meinung nach nur für kleine Webauftritte geeignet. Dynamische Versionskontrolle Zur dynamischen Versionskontrolle zählen wir die Systeme, die nur einzelne Dateien, Daten oder Layouts sichern. Änderungen können somit für jeden einzelnen Bestandteil des Webauftritts zurückverfolgt werden. Dies führt jedoch dazu, dass es keine einheitliche Versionsnummer für den aktuellen Gesamtstand des Projektes gibt. Um auch Meilensteine in der Entwicklung festhalten zu können, ist es möglich, Labels einzubauen, deren Bedeutung und Funktion in den folgenden Abschnitten noch erklärt werden wird. Außerdem ist es hilfreich, die Ressourcen vor dem Zugriff anderer zu schützen oder Unterversionen eines Projektes zu erstellen. Auch diese Funktionen der dynamischen Versionskontrolle sollen in den folgenden Abschnitten erläutert werden. Das Erstellen von Labels dient in der Versionsverwaltung der Markierung von Meilensteinen. Dies ist notwendig, da für gewöhnlich die verwalteten Ressourcen unterschiedliche Versionsnummern haben. Ein Label ist eine zweite Versionsnummer, die jede Ressource erhält. So kann eine Ressource in der Version 1.2 gleichzeitig zur Labelversion 0.1 gehören. Wenn nun regelmäßige Labels durch den Versionsbaum gezogen werden, ist es auch möglich, dass eine Ressource in der Version 1.2 zu Label 0.1, 0.2 und 0.3 gehört. Dieser Fall ist gar nicht so selten, wie man auf den ersten Blick vermuten würde. Denn es gibt viele Ressourcen, die fast nie geändert werden. Somit bleibt auch deren Versionsnummer immer die gleiche, während sich die Labelnummern des Projekts fortsetzen. Da auch ältere Labels unter Umständen wiederhergestellt werden sollen, können die Labelnummern der Ressourcen auch nicht überschrieben, sondern nur angehängt werden. Zur Veranschaulichung soll Abbildung 1 dienen. Abbildung 1: Label durch vier verschiedene Dokumente

3 Als Beispiel kann die Freigabe eines neuen Layouts des Webauftritts der Firma XY dienen. Vor der Freigabe wird noch ein Label durch die aktuellen Ressourcen gezogen. Später wird festgestellt, das der neue Web-Auftritt die eingebundenen Graphiken teilweise falsch oder gar nicht anzeigt. Da der Fehler nicht sofort behoben werden kann, wird auf die Vorläuferversion des Web-Auftritts, die mit dem Label gekennzeichnet wurde, zurückgegriffen. Somit ist sichergestellt, dass die Kunden auch weiterhin einen funktionierenden Web-Auftritt zur Verfügung haben. Ein weiteres Problem entsteht bei der gemeinsamen Bearbeitung von Dokumenten. Es kann vorkommen, dass zwei Bearbeiter zur gleichen Zeit am selben Dokument Veränderungen vornehmen wollen. Dies kann dazu führen, dass eine Änderung zweimal gemacht wird oder dass beim Speichern des entsprechenden Dokuments Differenzen zwischen den zwei Versionen der Bearbeiter auftreten, welche dann behoben werden müssen. Als Beispiel dient wieder der Webauftritt der Firma XY. Es soll eine Webseite mit Produktinformationen geändert werden. Es gibt zwei Mitarbeiter aus zwei verschiedenen Abteilungen, die dies erledigen können. Der erste Mitarbeiter ist von der Fertigungsabteilung und will die technischen Daten aktualisieren. Der zweite ist von der Public-Relations-Abteilung und will den Beschreibungstext des Produktes ändern. Beide Mitarbeiter laden sich den aktuellen Datenbestand zur selben Zeit vom Server auf ihren Rechner und sind damit der Meinung, die aktuellste Version der Daten vor sich zu haben. Der erste Mitarbeiter ändert nun die technischen Daten des Produkts und speichert die Datei auf den Server. Der zweite Mitarbeiter ändert den Beschreibungstext und speichert seine Datei ebenfalls auf den Server, mit dem Resultat, dass die Änderungen des ersten Mitarbeiters überschrieben werden. Wenn das CM-System über einen Sperrmechanismus (Locking) verfügt hätte, wäre es Mitarbeiter zwei nicht möglich gewesen die Datei zur selben Zeit zu bearbeiten. Er hätte warten müssen, bis der erste Mitarbeiter seine Änderung auf den Server gespeichert hat und damit die Datei wieder frei gegeben hätte. Durch das Locking könnte auch sichergestellt werden, dass manche Ressourcen nur durch bestimmte und autorisierte Personen geändert werden. Dies wäre der Fall wenn Layout-Daten nur von Mitarbeitern der Design-Abteilung geändert werden dürfen. Manchmal kann es notwendig werden, zwei Entwicklungsstufen nebeneinander laufen zu lassen. Dies könnte der Fall sein, wenn ein Relaunch des Webauftritts bevorsteht. So können die Redakteure weiterhin ihre Inhalte ändern, während die Designer ein neues Layout anpassen. Hierbei wird zu einer Version eine Unterversion erstellt. Dies kann zum Beispiel ein Label des Auftritts in der Version 1.7 sein, die sich mit einem neuem Inhalt auf 1.8 ändert, während die Designer mit der Unterversion weiterarbeiten. Dies ist auch für einzelne Daten oder Dateien möglich. Es kann vorkommen, dass es durch das gleichzeitige Bearbeiten eines Dokuments (bei fehlendem Locking) oder durch das Zusammenführen zweier Subversionen zu Differenzen kommt. Dies war der Fall bei dem oben gezeigtem Beispiel mit den Mitarbeitern, die zur selben Zeit eine Datei bearbeitet hatten. Wenn sie kein Locking aktiviert hätten, könnten sie nun mit einem Zusammenführungsmechanismus (Merge) die beiden Versionen der Datei abgleichen. Ein solcher Merge kann auf verschiedene Arten realisiert werden: - Die einfachste, von der Implementierung aber auch aufwändigste für den Benutzer wäre es, die beiden Dokumente einfach zu öffnen und nach den Unterschieden von Hand zu suchen. - Die nächste Stufe wären dann Editoren, die beide Dokumente nebeneinander öffnen und Unterschiede farblich hervorheben. Ein solcher Editor wäre zum Beispiel Vim [vi.diff], den es sowohl für Linux als auch für Windows gibt. - Am komfortabelsten für den Benutzer wäre es natürlich, wenn der Abgleich von dem CM- System selbst durchgeführt werden würde. Dies ist aber nur bedingt möglich, da ein Programm zum Beispiel nicht entscheiden kann, ob es die gelöschte Zeile der einen Version oder die Änderung derselben Zeile in der anderen Version übernehmen soll.

4 CMS Versionskontrolle mit CVS Auf der bekannten Seite wird über eine CVS-Schnittstelle zur Versionierung in CM-Systemen folgende Aussage gemacht:... Doch fehlt eine Schnittstelle, mit der beliebige Clients auf CVS zugreifen können. Daher sucht man CVS Unterstützung in CMS vergeblich... [cm.de] Dieser Aussage kann man sich nicht so ohne Weiteres anschließen. Denn auch wenn die meisten kommerziellen CM-Systeme keine Schnittstelle zu CVS bieten, liegt der Gedanke, CVS in einem eigenen CM-System zu benutzen, sehr nahe. In den folgenden Abschnitten soll daher aufgezeigt werden, dass CVS einige der nötigen Eigenschaften für eine CMS-Versionierung besitzt und wie eine Schnittstelle integriert werden könnte. Um ausgewählte Ressourcen für andere zu sperren, kann man in CVS den Befehl unedit verwenden. Mit diesem Befehl wird die ausgewählte Datei für alle anderen Benutzer gesperrt und gegebenenfalls werden Mitarbeiter, die diese Datei ebenfalls verwenden, benachrichtigt. Somit wäre die erste Forderung nach Locking erfüllt [cvs]. Um einen Meilenstein in der Entwicklung zu markieren, gibt es in CVS die Befehle tag und rtag. Diese Befehle markieren eine Revision im Entwicklungs-Verzeichnisbaum. Diese Kennzeichnung als Revision findet genauso statt, wie sie von dynamischen CM-Systemen gefordert wird [cvs]. Subversionen vom aktuellen Entwicklungsstand kann man auch in CVS erzeugen. Dies wird durch den Befehl tag mit der Option -b, gefolgt vom Namen des neuen Unterbaums erreicht. Dies ermöglicht es den Entwicklern, verschiedene Versionen derselben Datei zu überarbeiten, ohne sich ständig gegenseitig abgleichen zu müssen. Am Ende der Entwicklung kann einer der beiden Zweige übernommen werden oder die beiden werden zusammengeführt. Beim Zusammenführen entstehen hierbei wieder dieselben Probleme wie beim oben beschriebenen Mergen bei CM-Systemen [cvs]. Dass die meisten CM-Systeme keine Schnittstelle für CVS anbieten, bedeutet nicht zwangsläufig, dass diese Schnittstelle zu aufwändig oder nicht funktional genug wäre. Es gibt eigentlich für jedes Betriebssystem CVS-Kommandozeilen-Tools, deswegen wäre es ohne großen Aufwand möglich, diese zu benutzen, um unter Zuhilfenahme von Kommandoaufrufen eine solche Versionskontrolle zu realisieren. Auch wenn die Ressourcen in Datenbanken verwaltet werden, könnte man diese auch jeder Zeit in ein Filesystem exportieren und dann mit CVS verwalten. Sinnvoll wäre dies beispielsweise bei zwei getrennten Systemen, einem Entwicklungssystem mit Datenbanken und einem Livesystem in welches dann per CVS die freigeschalteten Seiten exportiert und verwaltet werden. Dieses System hätte auch den Vorteil, dass die Seiten auf dem Livesystem statisch sein könnten, während die Verwendung des CM-Systems mit dynamischen Seiten vereinfacht würde. Bei einem CM-System, dass nur auf CVS basiert, ist die Frage der logischen Verknüpfungen noch zu klären. Es können zwar Verweise und Links, die die Dokumente enthalten, mit abgespeichert werden. Mit der Verwaltung und Konsistenzsicherung der Links ist CVS jedoch überfordert. Hierzu müsste eine Datenbank generiert werden, die sich mit der Konsistenz der Links beschäftigt. Da die Linkkontrolle nicht Thema dieser Arbeit ist, wird der Aufbau einer solchen Datenbank nicht näher ausgeführt, an dieser Stelle wird auf die Arbeit Mechanismen zur Einhaltung der Linkkonsistenz in Hypertextdokumenten von Natalia Ivachtchouk und Andreas Sattler verwiesen, die das Thema Linkkonsistenz ausführlich behandelt.

5 WebDAV und DeltaV Die beiden Protokolle WebDAV und DeltaV werden in CM-Systemen, beispielsweise WebDAV im CM-System Synkron.web ( verwendet. Das Kürzel DAV steht für Distributed Authoring and Versioning [dav.rfc]. Bei WebDAV und DeltaV handelt es sich um Protokolle, die plattformunabhängig implementierbar sind, weil sie auf HTTP/1.1 aufsetzen. Mit WebDAV sollte das Web zu einem großen Dateisystem [dav.intro] gemacht werden. Dadurch sollte es ermöglicht werden, eine Vielzahl von Datenquellen wie Datenbanken oder Dateisysteme einzubinden und die Daten direkt auf dem Server zu bearbeiten [dav.intro]. Der Zugriff auf die Daten erfolgt dabei über ihre URL. Dabei wurde, wie aus dem Namen ersichtlich, auch versucht, die Probleme, die bei einer verteilten Zusammenarbeit entstehen, zu lösen. So ist bei DAV ein Locking-Konzept vorhanden. DeltaV stellt darüber hinaus Methoden zur Verfügung, die man auch aus Versionsverwaltungs-Systemen kennt: Checkin, Update und Merge. Dabei nutzt DeltaV die Erweiterungen, die von DAV zur Verfügung gestellt werden. WebDAV Wie eingangs schon erwähnt, erweitert WebDAV das HTTP/1.1 Protokoll um einige Methoden und führt einige neue und interessante Konzepte, wie die Properties, ein. Locking in WebDAV Wenn mehrere Redakteure an einem Dokument arbeiten sollen, kann es bei fehlender Koordination zu Problemen kommen. Es kann geschehen, dass einer der beiden beim Hochladen seines Dokuments die Änderungen des anderen überschreibt. Aus diesem Grund sollte ein System, das verteilte Zusammenarbeit unterstützt, die Möglichkeit bieten, zu bearbeitende Daten für den Zugriff anderer zu sperren. Man lockt die Datei und hat das ausschließliche Schreibrecht oder, je nach System, auch Leserecht. Alle anderen müssen warten, bis man den Lock wieder aufhebt. Diese einfachste Form des Locking nennt man exklusives Locking. WebDAV bietet auch die Möglichkeit, so genannte shared locks zu verwenden [dav.rfc]. Der Sinn von shared locks ist nicht die Sperrung von Dateien, sondern die Realisierung eines Mechanismus, der andere benachrichtigt, dass ein bestimmter Redakteur nun eine Datei editieren möchte. Wie die Redakteure das weitere Vorgehen koordinieren, bleibt ihnen überlassen. Wenn ein Redakteur eine Datei bearbeiten will, werden alle anderen, die ebenfalls einen shared lock auf die Datei gelegt haben, benachrichtigt. Wichtig ist noch, dass bei DAV bislang nur write-locks vorgesehen sind und keine read-locks [dv.rfc]. Außerdem ist wichtig, dass nicht WebDAV für die tatsächliche Sperrung der Daten verantwortlich ist. Dies muss vom darunterliegenden System (CM-SYSTEMEN, Betriebssystem) realisiert werden [dav.rfc]. WebDAV ist nur ein Protokoll und liefert die Anweisung, eine Ressource zu sperren. Da die Verwendung von Locks jedoch stark vom System abhängig ist, ist die Unterstützung dieses Mechanismus von der WebDAV-Gruppe freigestellt [dav.rfc]. Das bedeutet, dass man einen normgerechten WebDAV-Server oder Client schreiben kann, der überhaupt kein Locking unterstützt oder nur eine der beiden Locking-Methoden. Ob und welche Methoden das System unterstützt, muss jedoch vom Benutzer abfragbar sein [dav.rfc].

6 WebDAV Properties Ziel bei der Entwicklung von WebDAV war es, das Netz zu einem großen Lese- / Schreib-Medium zu machen [dav.intro]. Um über das Web mit Ressourcen und Daten ebenso komfortabel arbeiten zu können, wie auf einem Dateisystem, braucht man einen gewissen Stock an Metadaten, also Informationen über die eigentlichen Nutzdaten. Wichtig ist dies vor allem bei der Suche nach Ressourcen anhand verschiedener Kriterien. Auch zur Realisierung von speziellen Features, wie dem Locking, oder den Versionierungs-Funktionen in DeltaV benötigt man die Möglichkeit, eine oft nicht unerhebliche Anzahl von Zusatzinformationen effektiv zu speichern, zu suchen und zu verändern [dav.rfc, cm.de]. Die herkömmliche Methode ist, Metadaten im HTTP-Header zu speichern. Für einige wenige Daten mag dies ausreichend sein, für die effektive Verwaltung von Metadaten ist jedoch eine Strukturierung dieser Daten nötig. Um dies zu gewährleisten, werden Metadaten in WebDAV in XML gespeichert. Durch die so mögliche Strukturierung lassen sich eine große Anzahl an Properties verwalten. Diese sind effizient zu durchsuchen und zu verändern. Darüber hinaus ist eine Erweiterung um neue Properties in XML einfach zu realisieren, da XML ja auf Erweiterbarkeit ausgelegt ist und die nötigen Mechanismen dafür bietet. Properties bestehen aus Namen-Werte-Paaren. Der Name einer Property besteht aus einer eindeutigen URI. Diese zeigt auf ein XML-Schema, das Auskunft über die Syntax und Semantik der Property gibt. Eindeutigkeit wird mit der Verwendung von XML-Namespaces gewährleistet, die als Präfix dem Property-Namen vorangestellt werden. Diese Eindeutigkeit sorgt für ein gleichmäßiges Verhalten der Property über verschiedene Ressourcen und Servergrenzen hinaus, da Verwechslungen mit anderen, gleichnamigen Properties vermieden werden [dav.rfc]. Es gibt zwei verschiedene Arten von Properties: dead properties und live properties. Bei live properties werden die Syntax und Semantik vom Server überwacht. Es gibt zwei Möglichkeiten, mit live properties zu arbeiten: ihr Wert kann vom Client gesetzt werden. Der Server überprüft dann ob die korrekte Syntax, dem assoziierten Schema entsprechend, eingehalten wurde. Sie kann aber auch ausschließlich vom Server verwaltet werden, das heißt, nur er darf die Property-Werte überhaupt verändern. Im Gegensatz dazu werden die dead properties komplett vom Client verwaltet und überprüft. Der Server speichert diese Werte nur, kümmert sich aber nicht weiter um ihre Korrektheit. Dies bleibt dem Client überlassen. Wenn eine Ressource mit LOCK gesperrt wurde, unterliegen nur die dead properties dieser Sperrung. Live properties können nicht gesperrt werden, da sie ja vom Server verwaltet werden und eine Änderung jederzeit möglich sein muss. Logische Gruppen und Verzeichnisse Collections WebDAV bietet die Möglichkeit, einzelne Ressourcen zu so genannten Collections zusammenzufassen. Eine Collection ist ebenfalls eine Ressource, die die URIs ihrer Mitglieder enthält. Sie kann, wie jede andere WebDAV-Ressource auch, eigene Properties enthalten. Mithilfe von Collections kann man Ressourcen in logische Gruppen einteilen sozusagen Verzeichnisse erstellen. Der Inhalt einer solchen Collection kann dann wie ein Verzeichnisinhalt angezeigt werden, wobei man natürlich auch nach verschiedenen Properties sortieren kann, wie dem Erstellungsdatum, dem Lock-Inhaber und der Größe. So wäre es beispielsweise möglich, für jeden Mitarbeiter ein eigenes Verzeichnis (eine Collection) zu erstellen, die Links auf die Dateien hat, die er bearbeiten soll. Mit der von WebDAV zur Verfügung gestellten COPY-Methode kann eine solche Collection kopiert werden. Hierbei kann man angeben, ob man nur die Collection-Resource an sich (also das Verzeichnis der Links) kopieren will, oder ob man die in der Collection indizierten Ressourcen selbst ebenfalls kopieren will. Das gleiche gilt für die Methode MOVE. In CM-Systemen wäre eine Nutzungsmöglichkeit die

7 Archivierung von älteren Versionen einer Seite. Die einzelnen Bestandteile einer Seite mögen auf verschiedene physikalische Verzeichnisse verteilt sein, jedoch kann man sie mit einer Collection gruppieren, die unter einer URL zugreifbar ist. Man kann diese Collection und die in ihr enthaltenen Ressourcen dann auch, wie oben beschrieben, mit einer deep copy ins Archiv kopieren. Ein anderes Einsatzgebiet wäre die Verwaltung von verschiedenen Versionen einer einzelnen Datei in einer Collection, eine Version-History also. Dies wird auch so ähnlich in DeltaV gehandhabt, wie wir später sehen werden. Kopieren, Löschen und Verschieben von Ressourcen Wie im oberen Abschnitt schon erwähnt, erweitert WebDAV das HTTP-Protokoll um Möglichkeiten, wie Methoden zum Kopieren und Löschen von Ressourcen. Diese Methoden sind neben der Einführung von logischen Verzeichnissen nötig, um ein verteiltes Arbeiten über das Web zu ermöglichen, denn die von HTTP zur Verfügung gestellten Methoden GET und PUT sind dafür bei weitem nicht ausreichend. Es kann beispielsweise sein, dass der Name einer Ressource geändert werden muss, weil der Name falsch geschrieben ist. Mit HTTP hätte man zwar die Möglichkeit, mittels PUT die Datei mit dem richtigen Namen auf den Server zu laden, die alte, falsch benannte Datei wäre aber immer noch da. Mit dem MOVE-Befehl kann die Datei direkt vor Ort umbenannt werden. Die Methoden MOVE und DELETE achten auf die Erhaltung die Linkkonsistenz innerhalb einer Collection, vorausgesetzt die betreffenden Ressourcen sind Bestandteile einer Collection: wird eine Resource gelöscht, so muß auch der Verweis auf sie innerhalb ihrer Collection gelöscht werden. Wenn eine komplette Collection gelöscht werden soll und eine Ressource innerhalb dieser Collection nicht gelöscht werden kann, so dürfen auch ancestors dieser Ressource nicht gelöscht werden. Es soll beispielsweise eine Collection gelöscht werden. Diese enthält den Verweis auf eine Ressource die jedoch aus bestimmten Gründen nicht gelöscht werden kann. Sollte sich nun auch das Verzeichnis /pics in der Collection befinden, dann müsste es auch gelöscht werden. /pics ist jedoch der ancestor [dav.rfc] von urlaub.jpg und darf nicht gelöscht werden, da das Löschen von urlaub.jpg fehlgeschlagen ist. Würde es trotzdem gelöscht, würde es zu Inkonsistenzen kommen, da urlaub.jpg noch da ist, aber nicht mehr über die gespeicherte URL erreichbar ist. Wird hingegen eine Ressource mit MOVE verschoben, so wird die alte URI in der Collection durch die neue ersetzt. DeltaV Ursprünglich sollte WebDAV auch Funktionen zur Versionsverwaltung bei einer verteilten Zusammenarbeit über das Web zur Verfügung stellen. Da die Entwicklung der WebDAV- Kernkomponenten mehr Zeit in Anspruch nahm, als angenommen, wurde die Entwicklung eines Versionsverwaltungs-Protokolls auf WebDAV-Basis von der DeltaV-Gruppe übernommen. Das Ziel von DeltaV ist es, ein Protokoll zu erstellen, über das Aufgaben zur Versionsverwaltung gehandhabt werden können. So sollen gleichzeitig mehrere Redakteure an einer Ressource arbeiten können. Mehrere Versionen einer Ressource sollen gespeichert und auch wieder abgerufen werden können. Von anderen Versionsverwaltungs-Systemen bekannte Funktionen, wie das Erstellen verschiedener Versionspfade, sowie das Zusammenführen (Mergen) von verschiedenen Versionen, sollen ermöglicht werden. Gleichzeitig sollen Versionen der Ressourcen auf den URL-Namensraum abgebildet werden. DeltaV setzt dabei auf die Funktionalität von HTTP/1.1 und WebDAV auf

8 [dv.chart]. Die DeltaV-Gruppe arbeitet wie die WebDAV-Gruppe im Rahmen der Internet Engineering Task Force (IETF). Neue Methoden in DeltaV DeltaV definiert eine Reihe von Funktionalitäten zur Versionsverwaltung, von denen hier einige genannt werden sollen: - CHECKIN, CHECKOUT, UNCHECKOUT - Labeling - Merging Die ersten drei Funktionalitäten sind die bekannten Standardfunktionen eines Versionsverwaltungs- Systems, wie sie im ersten Teil dieser Arbeit bereits beschrieben wurden. Die Art der Verwaltung der verschiedenen Versionen in DeltaV unterscheidet sich jedoch von der Art, wie dies in beispielsweise in CVS gemacht wird. Wie dieser Unterschied beschaffen ist und was passiert, wenn eine Ressource unter Versionskontrolle gestellt wird, erläutert der nächste Abschnitt. Arbeiten mit DeltaV Eine anfangs nicht unter Versionskontrolle stehende Ressource (eine versionable resource ) wird mit der Methode VERSION-CONTROL der Versionskontrolle überantwortet. Dieser Vorgang spielt sich in drei Schritten ab: 1. Zunächst wird eine so genannte version history resource (VHR) erzeugt. Diese ist vergleichbar mit einer Collection in WebDAV (es spricht auch nichts dagegen, sie als eine solche zu implementieren). Sie enthält URIs auf die verschiedenen Versionen der unter Kontrolle gestellten Ressource. Die VHR ist ebenfalls über eine vom Server vergebene URL ansprechbar. In der unter Versionskontrolle gestellten Ressource wird, in einer Property, ein Link auf ihre VHR angelegt. 2. Nun wird eine Kopie der unter Versionskontrolle gestellten Ressource erzeugt. Dabei werden die dead properties und der Body der Ressource kopiert. Diese Version ist nun die Version 1.0 der Ressource. Sie bekommt vom Server eine eigene URL zugewiesen und wird auch in der VHR verlinkt. Diese neue Ressource heißt version resource. 3. Die versionable resource wird anschließend in eine version controlled resource umgewandelt. Sie behält ihre alte URL und bekommt eine neue Property, checked-in, die einen Link auf die neue version resource (also die Kopie der version controlled resource ) enthält und bei mehreren Versionszweigen dazu dient, beim Auschecken den richtigen Zweig zu finden. Wie man sehen kann, sind die Versionshistorie und die einzelnen Versionen nicht zusammen in einer Datei gelagert, wie bei CVS. Außerdem werden die einzelnen Versionen nicht als Diff-Files gespeichert, sondern als vollständige Kopien. Diese sind untereinander mit Links auf die jeweiligen Vorgänger bzw. Nachfolger verlinkt. Wenn nun an einer unter Versionskontrolle stehenden Ressource gearbeitet werden soll, wird diese zunächst ausgecheckt. Ihr Inhalt sowie ihre dead properties werden in die version controlled resource kopiert. Nach der Bearbeitung wird die Ressource wieder eingecheckt. Der Inhalt dieser veränderten Ressource wird als neue Version gespeichert. War in der Zwischenzeit jemand

9 schneller und hat ebenfalls eine Version dieser Ressource gespeichert, so wird ein neuer Versionszweig eröffnet. In der checked-in Property in der version controlled resource wird die URL derjenigen Version festgehalten, in der der aktuelle Inhalt nach dem Einchecken gespeichert wurde. So kann man sicher gehen, dass man beim nächsten Auschecken die richtige Version aus seinem eigenen Zweig bekommt. Soll aus einer Verzweigung wieder ein einzelner Versionspfad entstehen, so bietet DeltaV auch Merging-Funktionen. Es ist möglich, Verzweigungen zu untersagen. Damit spart man sich, als Programmierer von Servern und Clients, viel Arbeit, da der erhöhte Verwaltungsaufwand und auch das Merging wegfällt. Allerdings kann man in DeltaV auch einzelne Ressourcen von der Möglichkeit einer Verzweigung ausnehmen. Diese erhalten die Property checkout-fork mit dem Wert forbidden. Verbreitung von WebDAV und DeltaV Es gibt eine Fülle von Programmen, die einen WebDAV-Client implementieren, wie die Microsoft Office-Produkte (ab 2000), Adobe Photoshop und Adobe Acrobat. Natürlich sind auch Webeditoren wie GoLive! und Dreamweaver mit von der Partie. In Microsoft Betriebssystemen können die so genannten Webverzeichnisse verwendet werden, die auf WebDAV beruhen. Zur Zeit existieren einige wenige DeltaV Implementationen, so gibt es ein Modul für den Apache Web-Server, das neben WebDAV auch teilweise DeltaV Funktionalität implementiert [mod.dav]. Das Versionsverwaltungs-System Subversion verwendet DeltaV (zusammen mit WebDAV) für sein Web-Interface [subv] Fazit Die statische Versionskontrolle sollte lediglich bei kleinen Web-Auftritten verwendet werden. Die dynamische Versionskontrolle hingegen eignet sich auch für große Web-Auftritte. Die beschriebenen Anforderungen müssen hierbei nicht alle integriert werden. Die Anzahl der erfüllten Anforderungen ist dabei ein Maßstab für die Qualität der Versionskontrolle. Das Versionskontrollsystem CVS lässt sich bei reduzierten Anforderungen auch für größere Web- Auftritte nutzen. Jedoch ist die Forderung nach Linkkontrolle nur mit einem zusätzlichen System möglich. Da die Linkkontrolle ein wesentlicher Bestandteil von etablierten CM-Systemen ist, wird sich CVS jedoch in großen CM-Systemen vermutlich nicht durchsetzen. Die Verbindung von WebDAV und DeltaV ist eine mächtige Verbindung, die als offenes Protokoll eine Vielzahl von Anwendungen integrieren könnte. Der große Vorteil ist, dass WebDAV und DeltaV offene Protokolle sind und es eine zunehmende Anzahl von Libraries gibt, die sie unterstützen [cm.de]. Die Tatsache, dass viele der Programme, mit denen man Inhalte für Webseiten produzieren kann, WebDAV unterstützen, ist ein großer Vorteil, wenn man ein CM- System hat, das ebenfalls WebDAV implementiert.

10 Quellenverzeichnis [dav.intro] Whitehead, E.: Collaborative Authoring to the Web:Introducing WebDAV. ASIS Bulletin, October Website: < [dav.rfc] Goland, Y., Whitehead, E., Faizi, A., Carter, S., Jensen, D.: Request for Comments HTTP Extensions for Distributed Authoring WEBDAV. The Internet Society, 1999 [cm.de] Voigt, I.: Aspekte der Versionskontrolle in Content Management Systemen.Auf Contentmanager.de, Oktober Website: < [dv.chart] Amsden, J., Moore, K., Faltstrom, P.: DeltaV Charter, September 1999 [dv.intro] Website: < deltav-intro: Whitehead, J.: DeltaV.Adding Versioning to the Web. Website: Website: < [dv.rfc] Clemm, G., Amsden, J., Ellison, T., Kaler C., Whitehead, J.: Request for Comments Versioning Extensions to WebDAV. The Internet Society, Website: < [mod_dav] Mod_DAV: A DAV Module for Apache. Website: < November 2001 [vi.diff] Oualline, S.:The Vim Book. SAMS, April Website: < [cvs] Cederqvist, P.: Version Management with CVS. Website: < [subv] Use of DeltaV in SubVersion. Website: < Januar 2002