Liebe Gemeinde, ich brauche Rat.

Wir versionieren unsere Software mit Mercurial, das sollte hier eigentlich deckungsgleich mit Git sein. Eine alte SVN-Gewohnheit haben wir beibehalten: Named Feature Branches welche i.d.R. immer ins zentrale Repo übernommen werden. Nur noch schnell als Bildchen:


Meine Geschichte ist folgende: Eine Software ist über lange, lange Zeit gewachsen und wird momentan runderneuert, vieles wird neu geschrieben. Bestehender Code wird für gewöhnlich nicht mehr groß umgewälzt, sondern nur durch neuen ersetzt oder entfernt.

So weit, so gut. Das kniffelige: Die bestehende Software ist nicht eingeschlafen, sie wird (unter oben abgebildetem Modell) stetig weiterentwickelt, neue Features kommen hinzu. Währenddessen bildet die "neue" Software mittlerweile schon ein eigenes Produkt, beide werden eine Zeit lang parallel vertrieben werden.

Ich will mit meinen Umbauarbeiten nicht in die Arbeiten der „alten Software“ reingrätschen. Deshalb suche ich mir ein Release (z.B. "1.1") und baue darauf auf: Mit Patches (also mutable changesets). Alle paar Wochen baue ich die Patches ab, wechsele auf das neuste Release und spiele die Patches wieder drauf. Das klappt natürlich nicht reibungslos da sich in der "alten Software" Dinge geändert haben. Für die Anpassungen daran benötige ich dann zwischen 30 und 120 Minuten, das ist kein Problem. Dann habe ich die „neue Software“ auf Basis der Features von z.B. „Release 1.2“.

Mein Problem hierbei: Die „neue Software“ nähert sich dem Punkt an welchem sie regulär angeboten werden soll. Und ich habe mit meinen Patch Queues keine feste Historie an denen ich in ein paar Monaten sagen könnte „Das ist Version XY, die wurde an Kunden A, B und C ausgeliefert“. Ich brauche Snapshots.

Das einzige was mir einfällt: In Mercurial kann man seine Patch-Queues wiederrum versionieren, denn die sind im Endeffekt in eigenes Repository. Vom Komfort her ist das aber wirklich Welten von unserem gewohnten, oben abgebildeten Modell entfernt. Da kann man glasklar sehen welche Features und Fixes in welchem zeitlichen Verlauf reinkamen und wie ein Feature entwickelt wurde.

Was gibt es für Alternativen? Die „Weiterentwicklung“ als einen einfachen Zweig im Repo zu betreiben traue ich mich schlichtweg nicht – Ich glaube nicht dass man ein groß angelegtes Refactoring betreiben kann und nachträglich immer wieder Änderungen aus dem „un-refactorten“ Teil übernehmen ohne dass sich da alles durcheinander würfelt.


Ich danke fürs Lesen und wünsche ein schönes Wochenende.

Zitat von Der schöne Günther:

Ich glaube nicht dass man ein groß angelegtes Refactoring betreiben kann und nachträglich immer wieder Änderungen aus dem „un-refactorten“ Teil übernehmen ohne dass sich da alles durcheinander würfelt.

Ich versteh Dich nicht!
Du gehörst doch eigentlich nicht zu den Leuten, die, weil sie einen Hammer haben alles in der Welt als Nagel betrachten.
Entweder hast Du zwei unabhängige Programme oder aber zwei Programme, die gemeinsame Teile (Module) haben. Im zweiten Falle müßtest Du die Module dokumentieren und nicht die Programme. Ob Deine Verwaltungssoftware das kann, keine Ahnung.

Gruß
K-H

Kannst du nicht den Feature-Branch der neuen Software als zweiten master definieren und dann einfach die "kleinen Bugdixes" hineinmergen?
In git (unf vermutlich auch hg) ist es doch kein Problem, wenn mal "nach links" und dann wieder "nach rechts" gemerged wird.

Ich bin mir nicht sicher, ob ich das Problem ganz verstanden habe. Geht es eigentlich um zwei getrennte Repositories oder um ein einziges Repository?

Also ich kann dir sagen, was ich mit Git mache, was möglicherweise so ähnlich ist. Ich bin aber auch kein Experte was Versionierungsstrategien angeht und lerne gerne dazu.

Mein Problem ist, dass ich den Linux-Kernel mit ein paar Patches betreibe, die irgendwann mal für Version 3.16 oder so geschrieben wurden (aktueller Kernel ist 4.10). Diese Patches applyen natürlich längst nicht mehr, weil sich vieles geändert hat. Ich will es so haben, dass diese Patches immer auf das neueste Release applyen. Dazu benutze ich git rebase.

Der Workflow ist wie folgt.

Angenommen, ich habe Version 4.7 bereits gepatcht. Die gepatchte Version ist getaggt mit "v4.7-patched". Als erstes wechsel ich zu diesem Tag.

markieren

Code:

git checkout "v4.7-patched"

Das Commit-Log sieht so aus:

markieren

Code:

git log --format=oneline

9976c0407c25d69c0f7c0c0c1c6aa99a875fede3 [PATCH] Patch 2 <-- obendrauf meine Patches
fb28d356d6f8b098a2aaed6638085bcffaab2329 [PATCH] Patch 1 <-- obendrauf meine Patches
523d939ef98fd712632d93a5a2b588e477a7565e Linux 4.7 <-- letzter regulärer Commit des Upstream-Linux
68093c43f352e4ad36cf1324bbdbd7c723a24dbc Merge tag 'ceph-for-4.7-rc8' of git://github.com/ceph/ceph-client
107df03203bb66de56e2caec3bde6d22b55480c5 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
88083e9845612826dfd44a5215647b4f6567317c Merge branch 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs
b1386cedda177b10fac009ca8d3681034f15b5b3 Merge branch 'akpm' (patches from Andrew)
...

Ich möchte jetzt diese Patches (Changesets) auf Version 4.8 portieren.

markieren

Code:

git rebase "v4.8"

(Jetzt dauert es ein bisschen und ich muss eventuell ein paar Konflikte auflösen.)

Anschließend sieht es hoffentlich so aus:

markieren

Code:

git log --format=oneline

9325f55909f3582a49f04d41ce574c82cb49674b [PATCH] Patch 2
d7334192f868c44a7717a21bcb494026138179bf [PATCH] Patch 1
c8d2bc9bc39ebea8437fd974fdbc21847bb897a3 Linux 4.8
f76d9c61d91343806e59335493806e87daf78947 Merge branch 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm
117e5e9c4cfcb7628f08de074fbfefec1bb678b7 ARM: 8618/1: decompressor: reset ttbcr fields to use TTBR0 on ARMv7
be67d60ba944bdd38571b79bdcd506e34c0f16c1 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
66188fb11a82692629e85b6cbc3ecc08c752d2dc Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus
...

Man beachte dass dort jetzt "Linux 4.8" steht statt "Linux 4.7". Und wieder sind "meine" Patches oben drauf, so als wären sie als letztes committed worden – das ist das wichtige.

Nun bin ich schon fast am Ziel. Jetzt muss ich den Zustand nur noch archivieren:

markieren

Code:

git tag "v4.8-patched"

Fertig.

Durch den Tag ist dieser Zustand nun eindeutig und für immer identifizierbar. Und ich kann jederzeit mit git checkout zu früheren Tags zurück. (Ich kann z.B. danach wieder zu "v4.7-patched" zurück und sehe dann wieder das erste Log. Die Patches "verschwinden" also nicht von dort oder so.)

Hoffe es war nicht am Thema vorbei.

Zitat von jfheins:

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:

1. "NewSoftware"-Zweig spaltet sich von "AlteSoftware" in Version 1.1 ab
2. Im Code an Stelle X wird im "AlteSoftware"-Zweig etwas geändert
3. In "NewSoftware" wird an Stelle X und Y etwas geändert
4. In "AlteSoftware" wird an Stelle Y etwas geändert
5. "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...

Zitat von Namenloser:

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.

Zitat von Namenloser:

[...]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...