nicht angemeldet
Hallo Sven,
Will man das denn? Ich denke, wenn man einen neuen Zweig eröffnet, hat man hinterher nicht einen Ort, an dem Probleme gelöst werden müssen, sondern schon zwei. Also mitunter doppelte Arbeit, und in jedem Fall mehr Organisationsaufwand.
Branchen bedeutet ja nicht, dass es keine Kommunikation aktueller Weiterentwicklungen zwischen den einzelnen Zweigen gibt. Ein zeitweiliger Branch ist durchaus praktisch für langfristige Umbauten, Neuentwicklungen, Experimente, Dinge, die gerne versionskontrolliert werden möchten, aber nicht mit einem einzigen Commit abgetan sind. Im Ein-Personen-Kontext mit „Ein Problem pro Zeit“ ist das zugegebenermassen etwas seltener, aber durchaus auch praktisch. Im größeren Organisationsteam an einem größeren Projekt wird es aber durchaus praktischer.
Mal ein hypothetisches Beispiel anhand von SELFHTML: Abteilung Javascript beschliesst, jetzt Die Große Umorganisation Des DOM-Kapitels Des Jahres 2007 anzugehen. Nehmen wir mal einen größeren Prozess mit einer vollkommen neueren Struktur an, massiv hyperverlinkt bei der die DOM-Referenz mehr dem DOM-Baum folgt und auch z.B. Vererbungen wie im DOM darstellt. Also: Alle Seiten anders, alle Konventionen anders, eine Operation am offenen Herzen, hart am Rande des Neuschreibens, das durchaus etwas länger dauern kann.
Gleichzeitig will Abteilung CSS jetzt stückweise anfangen, neue kleine atomare Einzelstücke von CSS ins CSS-Eigenschaften-Kapitel einzusortieren, Abteilung Webserver will das und das und noch was ganz anderes machen und Abteilung Gesunder Menschenverstand will gerne Bugs verbessern, sobald diese auftreten. Diese Fraktion will also gerne die Weiterentwicklungen an SELFHTML im schnelleren Rythmus veröffentlichen, während Abteilung Javascript mehr mit einer Klausur geholfen wäre.
Also zweigt Abt. JS. einen DOM-Rewrite-Zweig ab und arbeitet dort an der großen Umstrukturierung, während der Rest an normalen Trunk weiterarbeitet und dort nicht so riesige Neuerungen aber dafür Veröffentlichungen macht. Team JS verfolgt die Änderungen im Trunk und mergt diese mehr oder minder regelmäßig in ihren Zweig ein, so dass dieser auf dem aktuellen Stand bleibt. SELFHTML als Dokumentation ist da perfekt für, da die Verpflechtungen zwischen den Dateien letztendlich nur Verweise sind, also relativ leicht zu mergen; Software ist da zugegebenermassen schwieriger.
Irgendwann ist das große DOM-Rewrite-Projekt fertig, SELFHTML 8.2, 8.2.1, 8.2.2, 8.2.3 sind erschienen (hoffentlich kommt es niemals dazu ;). Also wird der DOM-Rewrite-Zweig wieder in den Trunk gemergt. Oder umgekehrt, ist doch der Nicht-DOM-Rest der Kapitel von SELFHTML durch das regelmäßige Mergen der Neuerungen im Trunk in den Zweig auf einem neueren Stand als der Nicht-DOM-Rest im Trunk, der wegen Veröffentlichungszwang keine angepassten Verweise besitzt.
Klar hat man einen etwas höheren Organisationsaufwand beim branchen, das Mergen vom Trunk. Aber wenn man nur in einem Gesamttrunk arbeitet, kann man irgendwann nur noch ganz kleine Schritte unternehmen, weil man dann die Gefahr läuft, etwas so durcheinander zu bringen, dass man andere mit dem Wunsch des schnelleren Veröffentlichungen bremst. Größere Schritte wie größere Umbauten wirken sich dadurch dann auf die Veröffentlichungen aus.
Zurück zu Bazaar: Hier ist jede Working Copy ein eigener Branch, in dem man selbst committen kann, wie man lustig ist. Ein zentraler Branch existiert nur durch soziale Kontrolle, d.h. eine Kopie, auf der sich jeder verständigt hat, dass das der Trunk sei. Der klassische Commit aus der Working Copy ins zentrale Repository ist hier mehr ein Mergen. Das mag extrem erscheinen, ist aber letztendlich nur ein Weiterdenken des Gedanken dass so eine Entwicklung kein Baum mit sich abzweigenden Ästen ist, sondern mehr ein mäandernder Fluss mit unzähligen Nebenläufen, die wieder zum Fluss zurückkehren oder mit ihm durch kleine Bäche verflochten sind.
Tim