Subversion: Unterschied zwischen den Versionen

aus GlossarWiki, der Glossar-Datenbank der Fachhochschule Augsburg
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 20: Zeile 20:
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).
Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: <tt>cvs2svn</tt> (CVS to Subversion Repository Converter).


==Server Einrichten==
Das [[Repository]], auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet.


==Beispiele==
Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:
Beispiele machen sich auch nicht schlecht.


<code>svnadmin create <repository></code>


Für <code><repository></code> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher Datenbank-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:
*'''Berkeley DB''': Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.
*'''fsfs''' baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über Netzwerke gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.
Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-Server. Hier soll der einfachere Weg über den Server erklärt werden:
Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien <code>conf/svnserv.conf</code>, <code>conf/authz</code> und <code>conf/passwd</code>.
Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:
<code>svnserve –d –r .</code>
Der Parameter <code>d</code> bewirkt, daß der Dienst als Deamon gestartet wird und <code>r</code> gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.


==Geschichte==
==Geschichte==
Zeile 46: Zeile 63:
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)
* [http://better-scm.berlios.de/comparison/comparison.html Vergleich von 13 Versionsverwaltungen] (en.)


==Siehe auch==
[[Kategorie:Versionsverwaltung]]
[[Kategorie:Versionsverwaltung]]

Version vom 5. Juli 2006, 22:44 Uhr

Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.

Definition

Eine Versionsverwaltung hat die Aufgabe, den Werdegang eines Projektes zu protokollieren. Sie übernimmt die Versionierung und die Archivierung der Daten und ermöglicht den gemeinsamen Zugriff darauf. Dabei kann jede Änderung und jeder Stand verfolgt, rückgängig gemacht oder wiederhergestellt werden.

Subversion

Bis zum Jahr 2000 entwickelte sich CVS zum de-facto-Standard in der Open-Source-Gemeinde. Allerdings tauchten zunehmend Bugs und umständliches und fehlerhaftes Verhalten von CVS auf, was Anfang 2000 CollabNet Inc. dazu veranlaßte, Entwickler für eine Ablösung von CVS zu suchen. Ziel war es, eine komplett neue Versionsverwaltung, auf einigen guten Ideen von CVS aufbauend, zu entwickeln – allerdings ohne dessen Fehler und zusätzlich den Anforderungen der modernen Softwareentwicklung angepaßt. Im Februar 2000 begannen dann Karl Fogel und sein Freund Jim Blandy mit der Entwicklung von Subversion.

Hauptvorteile

Die Hauptvorteile – als Verbesserung zu CVS – sind nach dem offiziellen Handbuch:

  • Verzeichnisversionierung: Nicht nur einzelne Dateien, sondern der komplette Verzeichnisbaum wird mitversioniert.
  • Echte Versionsgeschichte: Dateien und Verzeichnisse können nun auch kopiert und umbenannt werden, ohne deren Historie zu verlieren.
  • Atomare Commits: Ein Befehl wird nun entweder komplett oder gar nicht ausgeführt. So ist es unmöglich, daß nach einem Fehler in einer Datei alle bisherigen Veränderungen erhalten bleiben.
  • Versionierte Metadaten: Jede Datei oder jedes Verzeichnis kann beliebige, zusätzliche Informationen – in Form von Schlüssel- und Wertepaaren – enthalten. Diese Informationen werden mitversioniert.
  • Auswahl der Netzwerkschicht: Subversion kommt entweder als Apache-Erweiterung oder als leichtgewichtiger Standalone-Server.
  • Konsistentes Datenmanagement: Nun können nicht nur aus Textdateien sondern auch aus Binärdaten Diffs erzeugt werden.
  • Effizientes Branching und Tagging: Der Aufwand steigt nun nicht mehr proportional zur Projektgröße an sondern ist immer gleich effizient.
  • API: Subversion kommt als eine Sammlung gemeinsamer C-Bibliotheken mit einer gut definierten API, auf die auch von externen Anwendungen zugegriffen werden kann.

Ein weiterer großer Vorteil, der zu dem großen Erfolg von Subversion geführt hat, ist die einfache Konvertierung eines alten CVS-Repositories in ein Subversion-Repository ohne Informationsverlust mit nur einem Befehl: cvs2svn (CVS to Subversion Repository Converter).

Server Einrichten

Das Repository, auch Archiv genannt, ist eine zentrale Referenzkopie aller Daten des Projektes inklusive der gesamten Versionsgeschichte, also aller alten Stände. Dieser Datenbestand wird auf dem Subversion-Server gespeichert und verwaltet.

Um ein neues SVN-Repository anzulegen, ist folgender Aufruf nötig:

svnadmin create <repository>

Für <repository> wird das anzulegende Unterverzeichnis, also der Repository-Name, angegeben. Als optionaler Parameter kann übergeben werden, welcher Datenbank-Typ das Repository verwenden soll. Standardmäßig wird fsfs ausgewählt. Folgende zwei Möglichkeiten stehen zur Auswahl, wobei jede ihre Vor- und Nachteile hat. Die genauen Unterschiede werden in beschrieben. Im allgemeinen wird aber eher zu fsfs geraten:

  • Berkeley DB: Dieses Repository baut auf der Berkeley Datenbank auf und ist seit 2001 im Einsatz. Das System ist sehr anfällig gegenüber Unterbrechungen und wird dann schnell instabil, auch belegt das Repository etwas mehr Speicher als mit fsfs. Dafür skaliert die Datenbank besser, wenn extrem viele Revisions-Bäume existieren. Sie ist ebenfalls etwas schneller, wenn nur die aktuelle Revision ausgecheckt werden soll. Bei vielen Dateien pro Revision ist sie jedoch wieder langsamer und hat Probleme, wenn verschiedene Benutzergruppen darauf zugreifen. Vorteil wiederum ist, daß vom kompletten System während der Laufzeit ein Backup gemacht werden kann.
  • fsfs baut auf gar keiner Datenbank, sondern nur auf dem Dateisystem, auf. Es ist ziemlich unempfindlich gegenüber Unterbrechungen und kann auch von Read-Only-Laufwerken und über Netzwerke gemounted werden. Das Repository ist etwas kleiner, hat aber bei veralteten Dateisystemen Skalierungsprobleme, wenn mehrere tausend Dateien in einem Verzeichnis existieren. Beim Einchecken großer Daten ist es etwas schneller, bei der aktuellen Revision dafür einen Moment langsamer. fsfs wird seit 2004 eingesetzt und die Programmierer empfehlen – außer es sprechen gute Gründe dagegen – alte Berkeley-DBs auf das fsfs-System umzuwandeln.

Um das nun erstellte Repository online zu stellen und den SVN-Server zu starten, existieren prinzipiell zwei Möglichkeiten: Als Apache-Plugin oder als Standalone-Server. Hier soll der einfachere Weg über den Server erklärt werden:

Zuerst muß noch festgelegt werden, wer welchen Zugriff und welche Rechte besitzt. Dies geschieht in den Dateien conf/svnserv.conf, conf/authz und conf/passwd.

Um den Server nun zu starten, ist aus dem SVN-Root Verzeichnis, welches die einzelnen Repositories enthält, folgendes Kommando notwendig:

svnserve –d –r .

Der Parameter d bewirkt, daß der Dienst als Deamon gestartet wird und r gibt das SVN-Root-Verzeichnis an – im obigen Fall also das aktuelle, da wir uns schon im richtigen Verzeichnis befinden.

Geschichte

SCCS

Das Source Code Control System (SCCS) war eine der ersten Versionsverwaltungen. Es wurde Anfang der Siebziger von Marc Rochkind bei AT&T entwickelt. Dieses System konnte schon mehrere Versionen einer Datei verwalten. Da es aber in jeder Hinsicht modernen Systemen unterlegen ist, existieren heutzutage praktisch keine Projekte mehr damit.

RCS

Das Revision Control System (RCS) war die erste große Versionsverwaltung im Open-Source-Bereich. Es wurde 1985 von Walter Tichy an der Purdue University entwickelt. Dabei kam zum ersten Mal eine Technik mit dem Namen Lock-Modify-Unlock-Mechanismus zum Einsatz. Damit können mehrere Benutzer auf eine gemeinsame Datei lesend zugreifen. Soll eine Änderung vorgenommen werden, muß die entsprechende Datei zuerst gesperrt werden. Danach kann kein anderer Benutzer die Datei mehr bearbeiten, bis diese wieder freigegeben wird. So wird zu jeder Zeit sichergestellt, daß nicht mehrere Benutzer gleichzeitig eine Datei verändern.

CVS

Die Weiterentwicklung von RCS ist das Concurrent Versions System (CVS). In den Anfängen, noch von Dick Grune in Shell-Skripten implementiert, wurde es dann 1989 von Jeff Polk und Brian Berliner in C komplett neu implementiert. Die größten Neuerungen waren sicherlich die eingeführte Client-Server-Architektur und der implementierte Copy-Modify-Merge-Mechanismus. Im Gegensatz zu RCS wird nichts gesperrt, sondern der aktuelle Stand vor einer Änderung in einen lokalen Workspace kopiert, indem dann auch die Änderungen stattfinden. Bei der abschließenden Veröffentlichung der Daten werden die Änderungen mit dem zentralen Repository wieder abgeglichen. Dadurch war es zum ersten Mal möglich, daß viele Benutzer gleichzeitig am selben Projekt, ja sogar in denselben Dateien, arbeiten konnten. Unterstützend kam noch hinzu, daß nicht, wie bisher, jede Datei komplett unabhängig von den anderen betrachtet wurde, sondern, daß nun Gruppen von Dateien zu Modulen zusammengefaßt werden konnten.

Quellen

  • Don Bolinger, Tan Bronson, Applying RCS and SCCS, O'REILLY, 1. September 1995, ISBN 1565921178
  • Gregor N. Purdy, CVS kurz & gut, O’Reilly Verlag, Köln, 1., korrigierter Nachdruck Dezember 2001, ISBN 3-89721-229-3
  • Derek Robert Price & Ximbiot, CVS - Concurrent Versions System, CVS-Homepage
  • Karl Fogel, Moshe Bar, Open Source-Projekte mit CVS, Verteilte Softwareentwicklung mit dem Concurrent Versions System, mitp-Verlag, Bonn, 2., erweiterte und überarbeitete Auflage 2002, ISBN 3-8266-0816-x
  • Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, Version Control with Subversion, For Subversion 1.1, book compiled from Revision 1337, 2005, http://svnbook.red-bean.com/
  • CollabNet, Inc., Subversion Homepage, Subversion-Homepage