Verzweigen oder nicht verzweigen – das ist eine interessante Frage. Bis hierhin hat dieses Kapitel einen ziemlich tiefen Tauchgang in die Tiefen des Verzweigens und Zusammenführens geboten. Themen, die historisch die Hauptquellen für die Verwirrung von Subversion-Anwendern waren. Als wären die routinemäßigen Aktionen zum Verzweigen und Verwalten von Zweigen manchmal noch nicht kompliziert genug, bleiben einige Anwender bei der Entscheidung hängen, ob sie überhaupt Verzweigen sollten. Wie Sie gelernt haben, beherrscht Subversion die üblichen Szenarien zum Verzweigen und für die Verwaltung von Zweigen. Die Entscheidung für oder wider das Verzweigen ist also selten technischer Natur. Stattdessen haben die sozialen Auswirkungen ein höheres Gewicht. Lassen Sie uns einmal einige der Vorteile und Kosten der Verwendung von Zweigen in einem Software-Projekt einmal untersuchen.

Der offensichtlichste Vorteil des Arbeitens auf einem Zweig ist Isolation. Auf dem Zweig gemachte Änderungen berühren nicht die anderen Entwicklungslinien des Projektes: Änderungen an diesen anderen Linien berühren nicht den Zweig. Auf diese Weise kann ein Zweig als großartiger Ort zum Experimentieren mit neuen Funktionalitäten, komplizierten Fehlerbehebungen, größeren Refaktorierungen usw. dienen. Egal, wie viel Sally auf ihrem Zweig kaputt macht, Harry und der Rest der Mannschaft können mit ihrer Arbeit ungehindert außerhalb des Zweigs weitermachen.

Zweige bieten auch eine großartige Möglichkeit, verwandte Änderungen in leicht handhabbare Sammlungen zu organisieren. Beispielsweise könnten die Änderungen, die die Komplettlösung eines bestimmten Fehlers ausmachen, eine Liste nicht-aufeinanderfolgender Revisionsnummern sein. Sie könnten diese natürlichsprachlich als „Revisionen 1534, 1543, 1587 und 1588“ bezeichnen. Sehr wahrscheinlich werden Sie diese Nummern manuell (oder auf andere Weise) in einem Fehlerverfolgungs-Dokument festhalten. Wenn Sie die Fehlerbehebung auf andere Produktversionen anwenden möchten, müssen Sie sicherstellen, dass all diese Revisionen berücksichtigt werden. Wären diese Änderungen jedoch auf einem eindeutigen Zweig gemacht worden, könnten Sie sich bei Gesprächen, in Fehlerverfolgungs-Kommentaren und beim Portieren von Änderungen lediglich auf den Namen dieses Zweigs beziehen.

Es ist jedoch die unglückliche Kehrseite von Zweigen, dass eben jene Isolation, die sie so nützlich macht, zum Nachteil der kollaborativen Bedürfnisse der Projektmitarbeiter gereichen kann. Abhängig von den Arbeitsgewohnheiten Ihrer Kollegen im Projekt, könnte es sein, dass Änderungen, die auf Zweigen gemacht werden, nicht die Art konstruktiver Durchsicht, Kritik und Überprüfung erfahren, wie Änderungen an der Hauptentwicklungslinie. Die Isolation eines Zweigs kann Anwender dazu verleiten, bestimmte „beste Vorgehensweisen“ bei der Versionskontrolle aufzugeben, was zu einer Versionsgeschichte führt, die nachträglich schwierig zu überprüfen ist. Entwickler auf langlebigen Zweigen müssen manchmal besonders schwer arbeiten, um sicherzustellen, dass die Richtung der Entwicklung ihrer isolierten Kopie der Quellen immer noch mit der Richtung harmoniert, die ihre Kollegen auf den Hauptentwicklungslinien einschlagen. Diese Nachteile mögen für wahre Versuchszweige weniger problematisch sein, die zum Experimentieren mit den künftigen Quellen ohne die Absicht der Rückführung in die Hauptentwicklungslinie angelegt werden – bloße Richtlinien brauchen keine Visionen abwürgen! Doch es bleibt die einfache Tatsache, dass Projekte allgemein von einem geordneten Ansatz für Versionskontrolle profitieren, bei dem der Quelltext und Änderungen daran die Begutachtung und das Verstehen von mehr als einem Teammitglied genießen.

Das bedeutet nicht, dass es beim Verzweigen keine Einbußen gibt. Verzeihen Sie bitte, wenn wir hier für einen Augenblick auf „die Metaebene gehen“. Wenn Sie darüber nachdenken, erzeugen Sie jedes Mal irgendwie einen Zweig, wenn Sie eine Subversion-Arbeitskopie auschecken. Es ist ein besonderer Zweig. Er lebt nur auf Ihrem Client-Rechner, nicht im Projektarchiv. Sie synchronisieren diesen Zweig mit Änderungen im Projektarchiv, indem Sie svn update aufrufen – das sich beinahe als Spezialfall wie eine vereinfachte Form eines svn merge-Befehls verhält.^[49] Gewissermaßen reintegrieren Sie Ihren Zweig jedes Mal, wenn Sie svn commit aufrufen. In diesem Sinn haben Anwender von Subversion ständig mit Zweigen und Merges zu tun. Angesichts der Ähnlichkeiten der Aktualisierung und Zusammenführung ist es deshalb nicht überraschend, dass die Bereiche in denen Subversion die meisten Schwächen zu haben scheint – nämlich die Behandlung von Umbenennungen von Dateien und Verzeichnissen sowie, generell, bei Baumkonflikten – sowohl für die Operationen svn update und svn merge problematisch sind. Unglücklicherweise hat es hierbei svn merge schwerer, da im Gegensatz zum vereinfachten Sonderfall einer Merge-Operation mit svn update eine echte Zusammenführung in Subversion weder ein besonderer Fall noch vereinfacht ist. Aus diesem Grund verlaufen Merges auch wesentlich langsamer als Aktualisierungen, erfordern die explizite Aufzeichnung (über die Eigenschaft svn:mergeinfo, die wir in diesem Kapitel erörtert haben) sowie Arithmetik zur Geschichtsbearbeitung und bieten im Allgemeinen viel mehr Angriffsfläche für etwas, das schiefgehen kann.

Verzweigen oder nicht verzweigen? Letztendlich hängt es davon ab, was Ihr Team benötigt, um das süße Gleichgewicht zwischen Zusammenarbeit und Isolation zu finden.