Versionsverwaltung - UOS-Open-Source-Softwareentwicklung/oss1314 GitHub Wiki

Versionsverwaltung

Kurzbeschreibung eines Open-Source-Tools

Sebastian Brockmeyer, [email protected], Universität Osnabrück

Aufgaben

Versionsverwaltungssysteme haben das Ziel, den Entwicklungsprozess von Software zu unterstützen. Zu den wichtigsten Aufgaben einer Versionsverwaltung gehören die Protokollierung der Entwicklung, die Möglichkeit der Archivierung und Wiederherstellung von alten Versionen und die Koordination des Zugriffs mehrerer Entwickler auf die selbe Datei. Historisch haben sich dabei drei Genres von Versionsverwaltungssystemen entwickelt: die lokale, die zentrale und die verteilte Versionsverwaltung.

Lokale Versionsverwaltung

Bei der lokalen Versionsverwaltung werden die Dateien lokal auf einem Rechner gespeichert und versioniert. Die Versionierung erfolgt nur dateiweise, nicht projektweise. Bei großen Projekten ist das problematisch. Da jede Datei ihre eigene Versionshistorie hat, ist es nicht ohne Weiteres möglich, mehrere Dateien auf einmal auf die Version zurückzusetzen, die sie zu einem bestimmten Zeitpunkt hatten. Beispiele für diese Art von Versionsverwaltungssystemen sind Source Code Control System (SCCS, 1972) [1] und Revision Control System (RCS, 1980) [2]. SCCS ist bis heute der POSIX-Standard für Versionsverwaltungssysteme. [1]

Zentrale Versionsverwaltung

Der zentralen Versionsverwaltung liegt ein Client-Server-System zugrunde. Alle Versionen und die Versionsgeschichte werden nur auf dem Server gespeichert, während die Clients nur die jüngste bzw. die eigene Version halten. [3] Die Versionierung erfolgt projektweise, das heißt beim Erstellen einer neuen Version wird das Projekt als Ganzes mit einer neuen Versionsnummer versehen und nicht nur die veränderten Dateien. Auf diese Weise ist auch die Verwaltung großer Projekte möglich.

Populär wurde die zentrale Versionsverwaltung durch Concurrent Versions System (CVS). [4] CVS benutzt allerdings intern das Speicherformat von RCS, sodass intern immer noch jede Datei ihre eigene Versionshistorie besitzt. RCS wird seit 2008 nicht mehr weiterentwickelt und wird daher heute nur noch selten benutzt.

Weiter Beispiele für zentrale Versionsverwaltung sind [3]

  • Team Foundation Server (Microsoft),
  • Visual SourceSafe (Microsoft),
  • Rational Synergy (IBM) und
  • Subversion (Open-Source).

Verteilte Versionsverwaltung

Im Gegensatz zur zentralen Versionsverwaltung basiert die verteilte Versionsverwaltung nicht auf einem zentralen Repository. Es existiert auch keine zentrale Versionsgeschichte. Stattdessen hat jeder Entwickler sein eigenes Repository mit einer eigenen Versionsgeschichte. Die Entwickler können ihre Repositories untereinander Abgleichen. Gleiche Dateien werden dabei automatisch gemerged, wobei ggf. eine manuelle Nachbehandlung notwendig ist. Auf diese Weise ist es nicht nur möglich, dass mehrere Entwickler die selbe Datei gleichzeitig bearbeiten, sondern der Regelfall.

Bekannte verteilte Versionsverwaltungssysteme sind unter Anderem [3]

  • Git,
  • Mercurial,
  • GNU arch,
  • Fossil,
  • Git und
  • BitKeeper (kommerziell).

Konzepte beim zeitgleichen Zugriff auf eine Datei

Pessimistische Versionsverwaltung

Die Pessimistische Versionsverwaltung folgt dem Prinzip "Lock Modify Write". Eine Datei muss erst gesperrt (lock) werden, bevor sie bearbeitet werden kann (modify). Erst nachdem die Bearbeitung abgeschlossen und die Datei gespeichert worden ist (write), kann sie erneut von anderen gesperrt und bearbeitet werden. [3]

Dieses Prinzip erfordert, dass die Entwickler die Möglichkeit haben, sich untereinander abzusprechen, um lange Wartezeiten auf die Freigabe einer Datei zu minimieren.

Beispiele für dieses Kozept sind RCS und Visual SourceSafe. [2][5]

Optimistische Versionsverwaltung

Bei diesem Konzept können mehrere Entwickler gleichzeitig eine Datei bearbeiten. Die so entstehenden unterschiedlichen Versionen einer Datei können dann automatisch oder bei Konflikten auch manuell verschmolzen (merge) werden. Absprachen unter den Entwicklern sind nur im Nachhinein bei Konflikten nötig, und auch dann nur, wenn zwei getätigte Änderungen inkompatibel erscheinen. Besonders bei Open-Source-Projekten ist das ein Vorteil, da sich die Entwickler nur selten im selben Raum befinden oder auf andere Weise kontinuierlichen Kontakt haben. [3]

Git

Git ist ein Beispiel für ein verteiltes Versionsverwaltungssystem. Es ist Open-Source und steht unter der GPLv2. Es wurde von Linus Torvalds entwickelt mit dem Ziel, die Entwicklung seines Linux-Kernels zu verwalten. [6] Ursprünglich verwendete er hierfür BitKeeper [7]. Doch als dieses seine freie Lizenz 2005 zurückzog, entschied sich Torvalds, ein eigenes Versionsverwaltungssystem zu implementieren.

Bei Git besitzt jeder Entwickler ein eigenes Repository mit allen Dateien. Dabei sind alle Repositories gleichberechtigt, häufig gibt es aber ein "offizielles" Repository, über das der jeweils aktuellste Stand öffentlich zugänglich gemacht wird (vgl. GitHub). Außerdem sind sogenannte Branches (Entwicklungszweige) fester semantischer Bestandteil von Git. Mit ihnen können mehrere Abzweigungen vom Haupt-Branch (master) erstellt werden, um parallel mehrere Features zu entwickeln und später durch einen Merge wieder zusammenzuführen.

Subversion

Subversion (svn) ist ein Beispiel für ein zentrales Versionsverwaltungssystem. Es wird seit dem Jahr 2000 von CollabNet entwickelt als Weiterentwicklung von CVS. 2004 Wurde die erste stabile Version veröffentlicht. Seit 2009 steht Subversion unter der Apache2.0 Lizenz. [8]

Subversion benutzt ein zentrales Repository, das meist auf einem Server liegt, aber auch im eigenen Dateisystem liegen kann. Die Klienten haben jeweils nur eine lokale Arbeitskopie. Im Gegensatz zu Git kennt Subversion keine eigene Branch-Semantik. Stattdessen werden Branches durch simple Kopien realisiert. Es hat sich dabei bewährt, die Basisverzeichnisse trunk, branches und tags anzulegen. An diese Bezeichnungen müssen sich dann alle Entwickler halten. [9]

Referenzen