Kannst du nicht den Feature-Branch der neuen Software als zweiten master definieren und dann einfach die "kleinen Bugdixes" hineinmergen?
In der Theorie, klar. Aber es sind nicht einfache 1-commit-fixes, sondern teilweise neue Features. Teilweise wird der alte Code nochmal richtig erweitert. Mein Problem mit den Merges ist dass ich mich vor den Automatismen fürchte:
- "NewSoftware"-Zweig spaltet sich von "AlteSoftware" in Version 1.1 ab
- Im Code an Stelle X wird im "AlteSoftware"-Zweig etwas geändert
- In "NewSoftware" wird an Stelle X und Y etwas geändert
- In "AlteSoftware" wird an Stelle Y etwas geändert
- "AlteSoftware" ist nun auf Version 1.2
Ohne es wirklich ausprobiert zu haben denke ich dass die Merge-Automatismen immer irgendetwas verschlucken werden da es ja im zeitlichen Verlauf
danach passiert ist. Vielleicht sollte ich es mal probieren...
Also ich kann dir sagen, was ich mit Git mache, was möglicherweise so ähnlich ist.
Das ist im Endeffekt das gleiche, vielen Dank!
Das Rebase in Git ist sehr ähnlich zu den Patch Queues in Mercurial. Bei mir geht es momentan in Richtung 500 Patches, sind also schon ein paar.
[...]Jetzt muss ich den Zustand nur noch archivieren[...]
Und der Schritt fehlt bei mir völlig. Ich habe die Patches vor meinem Rebase immer wieder komplett abgeräumt. Wäre ich schlau gewesen, hätte ich sie einmal fest ins Repo einkopiert. Dann kann ich sie auch taggen. Dann wechsele ich auf die neuste Version und stapele da wieder alles drauf.
Ich grübele mal etwas weiter, einer von euren beiden Wegen wird es wohl werden...