namespace cpp

C++ lernen, kennen, anwenden

Benutzer-Werkzeuge

Webseiten-Werkzeuge


vcs:why

Versionskontrolle

Durch Schaden wird man klug,
Sagen die klugen Leute.
Schaden litt ich genug,
Doch bin ich ein Tor noch heute.
— Friedrich Rückert

"Versionskontrolle, was ist das?" höre ich ab und zu. Wenn du Computer nutzt und darauf keine Antwort hast, solltest du diesen Artikel vermutlich lesen. Ein Programmierer sollte damit vertraut sein. Schütze Deine Quellen. Das gilt nicht nur für Mineralwasserproduzenten, Geheimdienstler und Journalisten. Neuere Versionskontrollsysteme wie Mercurial und Git nutzen ein verteiltes Konzept.

Was ist Versionskontrolle?

Typische Fragen

Wie kann ich …

  • meine Daten wiederfinden?
  • den Arbeitsstand von heute vormittag, letzte Woche, vom xx.xx.xx einsehen?
  • diesen Stand wiederherstellen, ohne ein funktionierendes Projekt kaputt zu machen?
  • erkennen, was wann/von wem geändert wurde?
  • die Übersicht über viele Dateien und deren Änderungen behalten?
  • Varianten ausprobieren, ohne ein funktionierendes Projekt kaputt zu machen?
  • verschiedene Entwicklungslinien wieder zusammenführen?
  • meinen Arbeitsstand an verschiedenen Orten/Computern abrufen und abgleichen?
  • meine Ergebnisse anderen mitteilen?
  • andere an meinem Projekt beteiligen?

Auf jede dieser Fragen gibt es unterschiedliche Antworten, es gibt aber auch für alle eine einheitliche — Versionskontrolle. Kurz gesagt geht es darum, wie und nach welchen Grundsätzen du deine Arbeit organisierst.

Aufgaben

Für die dauerhaft erfolgreiche Arbeit am Computer gibt es ein paar Grundregeln, die aber von verblüffend vielen verblüffend häufig missachtet werden:

  • Keep it strictly simple (KISS-Principle). Versuche nicht, "clever" zu sein. Fehler zu finden ist schwerer als sie einzubauen.
  • Schreibe Klartext. Einfaches Textformat wird nicht bei Versionswechseln unlesbar. Es lässt sich bei Systemwechseln leicht portieren. Programmquellen sind nicht ohne Grund Klartext.
  • Entwickeln kostet Zeit und Mühe. Sichere Dein Arbeitsergebnis. Ohne Quellen wird ein Programm recht schnell unbrauchbar.
    • Speichere regelmäßig Kopien (Backups) davon, möglichst nicht auf der gleichen Festplatte, demselben Rechner, im gleichen Brandabschnitt, Flutkeller, Bombentrichter. Sichere ab, dass sich die Dateien aus den Backups wiederherstellen lassen.
    • Keine fadenscheinigen Ausreden, wie ich sie vor Jahren von einem meiner Schüler gehört habe: Meine Freundin (?!) hat auf meinem Entwicklungssystem einen Ego-Shooter installiert. Dabei ist der Rechner abgestürzt. Seitdem bootet er nicht mehr. — Diese Geschichte glaubt sowieso keiner, welche Freundin spielt schon typische Männerspiele?
  • Dokumentiere, solange du noch weißt, was du tust. Später wirst du dich nicht mehr erinnern.
  • Don't repeat yourself (DRY-Principle). Sei faul, in dem du Aufgaben beim ersten Mal richtig erledigst, nicht, indem du sie umgehst.
  • Automatisiere. Überlasse wiederkehrende Aufgaben der Maschine.
  • Kenne und nutze deine Werkzeuge richtig.

Solche als richtig erkannte Grundsätze umzusetzen und durchzuhalten, ist schwer, wenn deren Einhaltung Mehraufwand bedeutet, vor allem zu Beginn. Ein Versionsverwaltungssystem unterstützt

  • Dokumentieren und Zurücknehmen von Änderungen,
  • Abgleichen von Entwicklungszweigen,
  • Koordinieren von Teamarbeit,
  • Archivieren von Quelltext lokal und im Netz (Source-Code-Hosting).

Ist es einfach zu bedienen, wird es auch intensiv genutzt. Dann hilft es wirklich beim Verwalten des Quelltexts. Hier gilt allerdings: Selbst kleine Mängel eines solchen Systems sind vernachlässigbar gegen die Risiken und den Ärger, der aus der Nicht-Benutzung entsteht.

Ist das schon Versionskontrolle?

Kein längerer Text entsteht in einem Guss. Er wird wieder und wieder überarbeitet, verschiedene Fassungen, Versionen, entstehen. Eine Vorstellung davon liefert jeder Artikel der Wikipedia. Wikipedia archiviert alle Fassungen eines Artikels in seiner Datenbank. Jede der Fassungen ist weiterhin einsehbar, um sie zu vergleichen und im Falle von Vandalismus auch einfach wiederherstellen zu können. Wider alle anfängliche Skepsis funktioniert dieses offene System der Versionsverwaltung erstaunlich gut.

Die in diesem System angelegte Unmöglichkeit, unliebsame Textstellen endgültig zu löschen, und mangelndes technisches Verständnis verleitete 2008 einen Politiker zu einem Versuch der Internet-Zensur. Er klagte, um Wikipedia in Deutschland verbieten zu lassen, so dass http://wikipedia.de drei Tage lang in Deutschland für Leute unerreichbar war, denen es nicht gelang, die stattdessen angezeigte URL http://de.wikipedia.org in die Adresszeile ihres Webbrowsers zu kopieren.

Einige der Probleme, die mit Versionskontrolle zusammenhängen, lassen sich teilweise durch diszipliniertes Arbeiten oder softwareseitig lösen, aber das ist nicht sehr praktikabel:

  • Tarball: Versionen werden als Dateiarchive komprimiert und nummeriert. Die Entwicklungsgeschichte ist parallel zu protokollieren. Die Bezeichnung Tarball (Teerklumpen) rührt von den durch das Unix-Kommando tar erzeugten "tape archive"-Dateien her, die eine Auswahl von Dateien zu einer einzigen zusammenfassen.
  • Dateiabgleich: Bestimmte Programme, vorrangig Textbearbeitungsprogramme mit proprietären, binären Dateiformaten, können Versionen vergleichen und die Unterschiede hervorheben.
  • Versionierung: Ebenso können Änderungsverläufe innerhalb solcher Dateien gespeichert und durch farbliche Markierung, Durchstreichen oder Unterstreichen kenntlich gemacht werden.
  • Dateisperre: Anton und Bernd bearbeiten zugleich dieselbe Datei. Beim Speichern überschreibt Bernd unabsichtlich die vorher von Anton gespeicherten Änderungen. Das Betriebssystem bzw. das zugehörige Programm kann verhindern, dass dieselbe Datei von mehreren Entwicklern gleichzeitig geöffnet wird.

Verfügbare Systeme

Frühe lokale Versionskontrollsysteme wie SCCS und RCS sind nur noch wenig verbreitet. Für die Teamarbeit sind zentrale oder verteilte Ablagen (Repositories) erforderlich. Neben kommerziellen sind auch leistungsfähige freie Open-Source-Systeme verfügbar.

Pessimistische Systeme sperren beim Check-Out die bearbeitete Datei bis zum Check-In, um so Bearbeitungskonflikte zu verhindern (lock-modify-write).

Optimistische System erlauben hingegen mehrere Arbeitskopien, deren Änderungen beim Einchecken abgeglichen werden müssen (copy-modify-merge). Aufgrund ihrer Arbeitsweise sind alle verteilten Systeme optimistisch.

Zentrale Versionskontrolle

Zentrale Systeme wie Subversion (SVN) oder Team Foundation Server (TFS, Microsoft) benötigen für jede Aktion Netzzugriff. Dies kann bei langsamen Leitungen (Internetverbindung) viel Zeit in Anspruch nehmen. Damit entsteht eine negative Rückkopplung. Weil es lange dauert, wird das Einchecken / der Commit hinausgezögert. Während dieser Zeit sammeln sich viele Änderungssätze an. Damit steigt wiederum der Aufwand für den Abgleich und die Wahrscheinlichkeit von Bearbeitungskonflikten, die nur manuell aufgelöst werden können. Von Subversion-Nutzern ist zu hören, dass Einchecken und Mergen in großen Projekten nur dann erlaubt ist, wenn alle Tests bestanden wurden.

Pessimistische Systeme wie der veraltete und als völlig unbrauchbar betrachtete Visual Source Safe (VSS, Microsoft) leiden zudem unter der ständigen Blockade des parallelen Arbeitens.

Verteilte Versionskontrolle

Dezentrale Systeme mit mehreren, lose gekoppelten Repositories sind seit einigen Jahren auf dem Vormarsch. Versionen können lokal gespeichert und abgeglichen werden. Nur für den Repository-Austausch (clone, pull bzw. push) ist Netzzugriff erforderlich. Hier gilt: Commit early, merge often. Dies führte auch zum Namen Mercurial (Hg) für eines dieser Systeme, welches selbst an der Kommandozeile recht einfach zu bedienen ist, wie hier gezeigt wird. Sie sind zudem auch für Einzelplatzsystem nutzbar.

GUI-Tools

Grafische Werkzeuge wie TortoiseHg integrieren sich in den Windows Explorer, für Entwicklungsumgebungen (Eclipse, Visual Studio) gibt es Plugins.

Quellcode-Hosting

Zentrale und Haupt-Repositories verteilter Systeme können auf eigenen Servern angelegt oder im Internet gelagert werden (Source-Code-Hosting). Das erleichtert den Abgleich bei wechselnden Arbeitsorten. Besonders für Open-Source-Projekte existiert eine Vielzahl von Anbietern:

System Land seit Nutzung (Stand 2011)
SourceForge CVS, SVN, Git u.a. US 2000 > 3 Mio Nutzer
Google Code CVS, SVN, Git, Hg US 2005-2015 k.A.
Codeplex SVN, Hg, Git US 2006 > 30000 Projekte
GitHub Git US 2008 > 3,5 Mio Nutzer
Gitorious Git Norwegen 2008-2015 etwa 1/9 von GitHub
BitBucket Hg, Git Australien 2008 > 1 Mio Nutzer

Die Angebote werden durch Wikis und Bugtracker ergänzt.

Entscheidet man sich, Daten dort abzulegen, sollte man vorher das Kleingedruckte lesen. In welchem Land der Anbieter beheimatet ist, kann eine Rolle spielen (US-Exportbestimmungen, Patriot Act: "Schurkenstaaten", Zugriff staatlicher Stellen).

Bitbucket sticht dadurch hervor, dass neben quelloffenen auch unbegrenzt viele private Repositories angelegt werden können. Ohne Kosten können bis zu fünf Bitbucket-Nutzer Schreibberechtigung (push) erhalten. Für quelloffene Repositories genügt jedoch der wechselseitige Pull-Zugriff.

Dynamik quelloffener Projekte

Es ist beeindruckend, die Entwicklung großer Open-Source-Projekte zu verfolgen. Michael Ogawa hat diese als Filme visualisiert.

Grundbegriffe

Je nach System werden verschiedene Bezeichnungen benutzt, hier eine Auswahl der wichtigsten:

  • Version: Revision, Bearbeitungsstand einer Gruppe von Dateien, der mit Zeitstempel und Nutzerkennung versehen ist.
  • Repository: Behälter, Aufbewahrungsort für versionierte Daten.
  • Update: Aktualisieren, Aus-Checken, Überführen einer Version aus dem Repository ins Arbeitsverzeichnis.
  • Commit: (dt. festlegen, überantworten, bekennen, verpflichten), Ein-Checken, Übertragen der Arbeitsfassung als neue Version ins Repository.
  • Klonen: Kopie eines Repositories erzeugen, die unabhängig weiterentwickelt werden kann.
  • Branch: Zweig, Entwicklungslinie, Folge von Versionen, entsteht durch Abspaltung (Klonen, fork).
  • Konflikt: nach Verzweigung wurden in Datei sich widersprechende Änderungen vorgenommen.
  • Merge: Zusammenführen von Versionen bzw. Entwicklungslinien, Dateiabgleich, Auflösen von Konflikten.
  • Wiederherstellen: (engl. revert, rollback) Verwerfen der Arbeitsfassung, Übernahme einer älteren Version aus dem Repository.
  • Delta: Differenz, Änderungen zwischen zwei Versionen, sind zumeist platzsparender zu speichern.
vcs/why.txt · Zuletzt geändert: 2015-03-13 13:16 von rrichter