... Verteilte Versionskontrolle aber wird bleiben.

Vor einiger Zeit war Eric Sink bei mir im Stack Overflow Podcast und wir zogen über Versionskontrolle her, besonders über diese neumodischen Verteilten Versionskontrollsysteme wie Mercurial oder Git.

In der Sendung sagte ich folgendes: "Wenn das Verzweigen und Verschmelzen dort einfacher ist, heißt das nur, dass deine Kollegen wahrscheinlich viel öfter verzweigen und verschmelzen werden, und du wahrscheinlich viel öfter ratlos danebenstehen wirst."

Nun, ihr wisst schon, unsere Abrufsendungen werden nicht besonders gut vorbereitet; es kommen halt ein paar Leute zusammen und es wird viel heiße Luft gepumpt. Dann ist es auch ganz normal, dass wir dort Sachen sagen, die, um mich technisch auszudrücken, falsch sind. Meistens sind sie falsch im Detail, manchmal falsch in der Herangehensweise, oder sie sind falsch in Detail und Herangehensweise. Diesmal war es einfach nur falsch - genauso wie Rucola-Pizza oder Donut mit Ketchup: FALSCH!

Lange bevor diese Sendung erschien, hatte mein Team zu Mercurial gewechselt. Das hatte mich so verwirrt, dass ich extra jemanden angeheuert habe, um Kode für mich einzuchecken (Nein, nicht!, war nur ein Witz). Ich habe mich eine Zeitlang durchgewurstelt, hab mir eine Handvoll Kommandos gemerkt und gemeint, es wäre wie Subversion. Nur wenn dann doch etwas anders lief als gewohnt, war ich wieder verwirrt und musste ans andere Ende des Flurs, um mir Hilfe bei Benjamin oder Jacob zu holen.

Und dann sagte mir mein Team: Hey, weißt du was? Es ist wirklich beeindruckend, wie dieses Mercurial mit Fehlern umspringt! Wir würden gerne ein Produkt für Koderevision drum herumbauen, und außerdem ... wir vermuten hier einen echten Markt für kommerzielle Unterstützung und für eine Netzanwendung; Mercurial selbst ist frei verfügbar unter GPL, aber die meisten Firmen verlangen ja nach Support, bevor sie irgendetwas Neues benutzen.

Und ich dachte mir: Was weiß ich schon? Aber, wie Ihr schon wisst, treffe nicht ich hier die Entscheidungen, weil "Management eine Supportfunktion ist". Und so versammelten sie alle Internen, sechs an der Zahl, und machten sich daran, ein Produkt um Mercurial herumzubauen.

Ich wiederum beschloss herauszufinden, was es mit dieser höllischen Verteilten Versionskontrolle auf sich hat, bevor irgendjemand mir Fragen stellen würde, zu einem Produkt, das meine Firma angeblich verkauft, und ich keine Antwort wüsste, und ein anderer in der "Blogospäre" wieder mal schreiben würde, dass ich nur Mist erzähle.

Und ich las, und ich studierte, bis ich schließlich etwas erkannte, was ich nun mit Euch teilen will.

An der Verteilten Versionskontrolle ist das "Verteilt" nicht das Interessante.

Der interessante Teil ist vielmehr, dass diese Systeme von den Änderungen her und nicht von Versionen her denken. Das klingt sehr nach Zen, ich weiß.

Traditionelle Versionskontrolle denkt: OK, ich hab Version 1. Und jetzt hab ich Version 2. Und nun 3.

Und Verteilte Versionskontrolle denkt: Ich hatte nichts. Dann bekam ich diese Änderungen. Und dann bekam ich jene Änderungen.

Das ist ein ganz anderes Programm-Modell, also müssen wir unser Benutzer-Modell ändern.

Mit Subversion denkt man: "Bring meine Version in Einklang mit der Hauptversion" oder "Geh zurück zur vorherigen Version".

Mit Mercurial denkt man: "Hol mir Jacobs Änderungen" oder "Vergiss die letzten Änderungen".

Wenn du mit Subversion im Kopf an Mercurial herangehst, wird das meistens funktionieren, nur wenn nicht, lässt es dich verwirrt, unzufrieden und unglücklich zurück, und du wirst Mercurial hassen.

Wenn du aber mit einem offenen Geist die Versionskontrolle neu durchdenkst und du das Zen erkennst, wenn du dich einfühlst in den Unterschied zwischen dem Denken in Versionen und dem in Änderungen, dann wirst du erleuchtet und du wirst glücklich sein, und dir wird klar werden, dass Versionskontrolle nur so arbeiten sollte.

Eigenartig ist es schon ... seit 1972 glaubte jeder, es ginge ums Manipulieren von Versionen, doch dann stellt sich heraus, dass allein das Erkennen der Änderungen als grundlegend ein entscheidendes Problem löst: das Problem des Verschmelzens der verschiedenen (Versions-)Zweige.

Und das ist der wichtigste Punkt überhaupt, es ist wahrlich das Allerwichtigste, das wir in den letzten zehn Jahren in Bezug auf produktives Programmieren gelernt haben. Es ist dermaßen wichtig, das es verdient, meinen allerletzten Meinungsartikel hier zu zieren. Wenn du dir auch nur etwas merken willst, merk dir das:

Wenn du Änderungen statt Versionen verwaltest, dann funktioniert das Verschmelzen besser, und deshalb kannst du bedenkenlos verzweigen, sowie das deine Aufgaben von dir verlangen, weil das Verschmelzen hinterher ein Kinderspiel ist.

Ich kann gar nicht sagen, wie viele Subversion-Nutzer mir die folgende Geschichte erzählt haben: "Wir versuchten für unseren Kode einen neuen Zweig anzulegen, und das ging problemlos. Nur als es dann Zeit wurde, beide Zweige wieder zu vereinen, erlebten wir einen ausgewachsenen Albtraum, denn wir mussten praktisch jede einzelne Änderung per Hand überführen. Und wir schworen uns "Nie wieder!" und entwickelten eine neue Methode der Softwareentwicklung, in der wir mit if-Anweisungen arbeiten anstatt zu verzweigen."

Manchmal sind sie sogar ein wenig stolz auf ihre neue Nur-ein-Zweig-Erfindung. Als ob es ein Verdienst wäre, den Mangel der Versionskontrolle provisorisch zu umgehen; sie tut einfach nicht, was sie tun soll.

Mit Verteilten Versionskontrollsystemen ist Verschmelzen einfach und funktioniert. Man kann Zweige unterhalten für die stabile Version, für die Weiterentwicklung, oder auch langlebige Zweige für die QS-Gruppe, in der diese Sachen ausprobiert vor dem Entwickeln, oder auch kurzlebige Zweige, in denen du neue Ideen ausprobieren kannst.

Das ist zu wichtig, um es zu ignorieren. Es ist der vielleicht größte Fortschritt bei Entwicklungstechniken, den ich erlebt habe in den letzten zehn Jahren, in denen ich hier Artikel schrieb.

Um es anders auszudrücken: Eher würde ich zu C++ zurückgehen, als auf Mercurial zu verzichten.

Wenn ihr noch Subversion benutzt, hört auf damit. Lasst es einfach sein. Subversion, das heißt Schröpfköpfe und Blutegel. Mercurial und Git aber sind Antibiotika. Wir haben jetzt bessere Methoden.

Weil so viele in Mercurial eintauchen ohne das neue Programm-Modell ganz verstanden zu haben, weil es passieren kann, dass sie es für fehlerhaft und bösartig halten, deshalb habe ich eine Einführung zu Mercurial verfasst: HgInit.

Wenn mich heute jemand zu dem erwähnten Podcast befragt, in dem ich Verteilte Versionskontrolle so runtergemacht habe, dann erzähle ich, das sei nur ein sorgfältig geplanter "Wiedergutmachungs"-Schwindel gewesen, für meinen langjährigen Freund und Rivalen Eric Sink, der ein Nicht-verteiltes Versionskontrollsystem herstellt. Kurz zuvor nämlich hatte er mit dem Verkauf von Fehlerverfolgung-Software begonnen, und um ihn zu bestrafen, schickten wir ihm einen ziemlich teuren Fog-Creek-Rucksack zusammen mit einem gefälschten Formbrief, der es so aussehen ließ, als ob dieser teure Rucksack das Standard-Weihnachtsgeschenk wäre, das Fog Creek jedem Fog-Creek-Kunden schickt.

Mir scheint, meine Zeit an dieser Stelle ist abgelaufen. Es war mir eine große Ehre, Euch als Leser meiner Essays über zehn Jahre hinweg gehabt zu haben. Ich hätte mir keine bessere Leserschaft wünschen können. Ob Du jetzt einer von den mehreren Hundert warst, die freiwillig ihre Zeit geopfert haben, um Artikel in über 40 Sprachen zu übersetzen, oder einer der 22.894, die sich die Zeit nahmen mir eine Mail zu schicken, oder einer der 2.262.348, die jährlich diese Website besucht und einige meiner 1067 Artikel gelesen haben, ich danke Dir aufrichtig für Deine Aufmerksamkeit.