home  |  suche  |  kontakt/johner  |  institut 
studierende  |  tech-docs  |  mindmailer 

Einführung

Sobald man professionell, in einem Team und an mehreren Entwicklungsständen oder mehreren Produkten arbeitet, wird der Einsatz des Versionsmanagements notwendig. Solch eine Versionsverwaltung sollte

     

  • das unbeabsichtigte Überschreiben von Dateien durch mehrere Teammitglieder verhindern
  • es erlauben, zu einem beliebigen Zeitpunkt in der Historie eines Entwicklungsprojektes zurückzuspringen. Dies entspricht einer "Undo-Funktion" auf allen Artefakten eines Projekts
  • Nachvollziehbarkeit gewährleisten (wer hat wann was aus welchem Grund an dieser Datei geändert?)
  • das gleichzeitige Arbeiten an mehreren Releaseständen gestatten, oder dass die Entwicklung an einem "Strang" eingefroren werden müsste
  • über ein WAN zugreifbar sein

Wichtige Begriffe im Kontext eines Versionsverwaltungssystems sind

     

  • Repository: Die zentrale Instanz, auf der alle Versionnen aller Projektdateien liegen
  • Einchecken, commiten: Das Sichern einer Datei des Entwicklers in das Repository
  • Auschecken: Das initiale Übertragen der Dateien des Repositories (oder eines Teils) auf den lokalen Rechner des Entwicklers. Manchmal versteht man unter Auschecken auch das Sperren einer Datei im Repository für die anderen Entwickler
  • Aktualisieren: Das regelmäßige Abgleichen der lokalen Dateien mit dem Repository

Ein Repository kann realisiert werden als

     

  • Netzlaufwerk, über das mit WebDAV Delta V zugegriffen wird. *)
  • Client-Server-Anwendung, beispielsweise CVS (Concurrent Versioning System), Microsoft VSS, Rational Clear Case

 

*) WebDAV steht für "web-based distributed authoring and versioning" und bezeichnet eine Erweiterung des HTTP Protokolls, beispielsweise um die Methoden lock, move, propfind (Datei-/Verzeichnisattribute auslesen), mkcol (Verzeichnis anlegen). Der Aspekt der Versionierung wurde bei WebDAV jedoch nicht implementiert, was durch die Erweiterung Delta V nachgeholt werden soll.

Versionen und Tags

Das Repository, hier am Beispiel CVS, vergibt automatisch Versionsnummern. Mit jedem Einchecken wird die Versionsnummer erhöht.

Beispiel:

 

     

  • File1.java in Version 1.1
  • File2.java in Version 1.3
  • File3.java in Version 1.2

Würde nun zu einem späteren Zeitpunkt Y File1.java und File2.java geändert hätte das Repository folgenden Stand:

     

  • File1.java in Version 1.2
  • File2.java in Version 1.4
  • File3.java in Version 1.2

Damit wird klar, dass aus der Versionsnummer nicht auf einen Zeitpunkt geschlossen werden kann. Aus diesem Grund können die Dateien nicht über die Versionsnummern zu einem Release gruppiert werden. Man vergibt daher sogennante Tags (Etiketten). Es empfiehlt sich, dies Tags bei jedem neuen Release sowie vor und nach der Korrektur eines Fehlers  zu vergeben.

Mehrere Tags zweigen dann auf eine Version einer Datei, falls diese zwischenzeitlich nicht geändert wurde. Im obigen Beispiel hätte File3.java zwei Tags, falls zu den Zeitpunkten X und Y Tags vergeben worden wären.

 

Erzeugt man einen neuen Branch (s.u.) ändert sich die Versionsnummer beispielsweise von 1.3 auf 1.3.2.1 und bei weiteren Änderungen innerhalb des Branches auf 1.3.2.2.

Branches/Zweige

Die völlige Unabhängigkeit von verschiedenen Entwicklungsständen (Releases) erreicht man durch eigene Zweige, die wie ein zweites Repository innerhalb des Repositories zu sehen sind. Damit können die Entwickler zeitgleich Fehlerkorrekturen an einer abgeschlossenen Version der Software durchführen und für jede Korrektur ein eigenes (Minor-)Release erzeugen.

Gleichzeitig können die Entwickler an der nächsten Version (Major-Release) weiterarbeiten. Sie sollten nur sicherstellen, das die Korrekturen auf dem Zweig auch auf den Hauptstrang übertragen werden. Falls eine Datei sowohl im Hauptstrang als auch im Releasezweig geändert wurde, kommt es zu einem Konflikt. Hierbei unterstützt CVS durch automatisches Mergen, das nur für den Fall, dass die gleiche Zeile unterschiedlich geändert wurde manuelles Eingreifen erfordert.

Die nachfolgenden Zeichnungen, die dem Buch von Thomas und Hunt (s. Literaturverzeichnis)entnommen sind, zeigen das Branching und den Konflikt beim gleichzeitigen Bearbeiten einer Datei - einen Konflikt, den CVS selbständig lösen würde.

Strategie

Artefakte

Die folgenden Artefakte sollten unter Versionskontroller stehen

     

  • Quellcode
  • Buildscripts
  • Konfigurationsdateien
  • (Datenbank)
  • Dokumentation
    - Benutzer- und Entwicklerdokumentation (z.B.)
    - Besprechungsprotokolle
    - Konfiguration
    - Testbeschreibungen, Testergebnisse

Nicht unter Versionskontrolle sollten aller generierbaren Artefakte stehen wie

     

  • Kompilierte Dateien
  • JavaDoc
  • Jar-Dateien, so der Quellcode vorliegt

 

Repository

Das Repository kann mehrere Projekte beinhalten, die selbst wieder in Module unterteilt werden können, welche die einzelnen Dateien enthalten. Die Module können nach Schichten (z.B. Datenzugriff, Geschäftslogik, Client) oder auch innerhalb der Schichten (Kunden, Konten) gebildet werden.

 

Es gibt zwei unterschiedliche Mechanismen des Sperrens:

     

  1. Das pessimistische Sperren verbietet das gleichzeitige Bearbeiten einer Datei (Beispiel VSS)
  2. Das optimistische Sperren deckt Konflikte, die durch gleichzeitiges Bearbeiten entstanden sind, erst beim Einchecken auf und löst sie soweit als möglich automatisch.