Hello,
Worin seht Ihr den Vorteil dieser Vorgehensweise?
in unserem Versionsverwaltungssystem, wobei das eher der Grund für die Vorgehensweise ist. Zwar unterstützt das System (IBM Rational ClearCase) auch sowas wie Tags, aber ein Tag fasst zunächst mal nur einen Softwarestand zusammen, einen Tag kann man nicht weiterentwickeln, man kann nur sagen "gib mir den Code für das Tag 1.0". Wenn ich an den Code dran will brauch ich einen Branch, der auf diesem Tag basiert.
Szenario: Projekt, das in mehreren Iterationen entwickelt. Erste Iteration ist entwicklungstechnisch (Implementierung, Unit Test) abgeschlossen und geht nun in Integrations- oder Fachtest. Parallel dazu startet die nächste Iteration. Nun meldet der Test einen Fehler. Was definitiv NICHT geht, ist dass ich jetzt den Trunk ausliefere, da ist ja schon andere Funktionalität drin. Also fixe ich auf dem Branch, liefere dem Test den Branch aus und merge den Fix in meinen weiterentwickelten Code auf dem Trunk.
Klar, ich kann es genau umdrehen und die Weiterentwicklung auf dem Branch machen, bei uns wurde mal entschieden, dass es leichter ist Defects aus einem Branch in den Trunk zu mergen als Funktionalität aus einem Branch in eine bug-gefixte Version zu mergen, was vielleicht sogar kein Merge sondern ein Replace wäre. Schätzungsrationale vielleicht sowas wie "ich fixe 100 Defects, entwickele aber 300 Funktionen neu, was will ich jetzt lieber mergen"?
MfG
Rouven
-------------------
sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
Because good guys need a break every once in a while. -- Morty in "Click" (Columbia Pictures, 2006)