[linux-l] Nutzt jemand Git?

[Steffen Dettmer]

* Volker Grabsch wrote on Fri, May 29, 2009 at 19:44 +0200:
> > na ja, das kann beliebig kompliziert werden! Wenn man jetzt ein
> > 50KLOC diff auf einem zwei Jahre alten Branch in einen ein Jahre
> > alten Branch mergen muß, und wegen Strukturänderungen etc.
> 
> JFTR: Aus genau diesem Grund wird generell empfohlen,
> 
>     1) den Trunk (bzw. den "stable Branch") regelmäßig
>        in die anderen Branches zu mergen.

Ja, wenn das geht, wenn man also so ziemlich alles `backporten'
kann, lebt man in einer einfachen Welt...
Oft hat man aber Versionsbranches eben weil man das nicht möchte.
Sonst bräuchte man die Branches wohl auch kaum, würde man halt
nur neue Versionen warten (die ja theoretisch oft ja die Features
älterer Versionen auch haben).

> > Das funktioniert ja auch nur in einfachen Fällen. So ein `bis auf
> > paar Bugfixes alles trunk' Projekt kann sowas fordern, aber wenn
> > man wirklich viele Stände aktiv warten (inkl. neuer Features)
> > muß, hat man vermutlich immer das Problem, daß die Branches
> > sehr unterschiedlich sind (Produktlinien z.B.).
> 
> Ja, das ist ein Problem, und zwar eines, gegen das man IMHO
> frühzeitig vorgehen sollte - nicht erst, wenn die Branches
> schon Monate lang voneinander abgedriftet sind.

Wenn man z.B. nur eine Produktlinie hat, ist das natürlich
einfach, aber was ist, wenn man auf irgendeinem z.B. drei Jahre
alten Stand eine kleine neue Funktion entwickeln muß, weil man
keine aktuelle Version verwenden kann?
Das ist doch ein logisches Problem, dass kann kein VCS lösen.

> Dann müssen sich die entsprechenden Leute halt zusammensetzen,
> da hilft alles nichts. Aber die Aktion hat größere Chancen auf
> Erfolg, wenn der Code den Leuten noch gut im Gedächtnis ist,
> ergo: Nicht zu lange mit dem Merge warten und zur Not schonmal
> stabile Teile mergen. (siehe oben)

Das kommt darauf an, wie man `stabil' definiert. Ist
beispielsweise Timing oder Codegröße wichtig, wird es schnell
kompliziert. Man kann kein Teilfeature mergen, wenn z.B. an
anderer Stelle die Größenoptimierung noch nicht drin ist oder
durch einen zusätlichen Funktionsaufruf ein Subsystem plötzlich
zu lange laufen würde.

> > Auch die Idee, einfach oft und in kleinen Schritten zu mergen,
> > funktioniert nicht
> 
> Warum nicht? Was sollte einen daran hindern?

Wenn man nicht backporten kann, kriegt man jedes Mal Konflikte,
wenn sich z.B. Datentypen geändert haben oder so. Da muß man dann
u.U. bei jeder neuen Verwendung dieses Datentypes per Hand ran
(weil man z.B. das Umbenennen nicht backporten kann oder will).

Und wenn man alles backporten würde, wäre der alte Branch ja
funktionell gleich zum Trunk. Dann braucht man ja überhaupt
keinen (Versions-)Branch.

> > und ein Merge oder Konflikte heißt noch lange
> > nicht, dass das Ergebnis compiliert oder gar funktioniert.
> 
> Natürlich darf ein Merge erst dann eingecheckt werden, wenn
> dessen Korrektheit durch die Testsuite abgesichert ist. Das
> gilt aber generell für jeden "Commit". :-)

Nein, das gilt nicht generell.

Ich glaube nicht, dass so eine Regel häufig ist. Ich glaube,
meistens fordert man, dass der Code für die wichtigeste(n)
Platformen kompilieren soll, bevor man eincheckt. Testsuite muß
IMHO nicht unbedingt laufen, das kann ja beliebig kompliziert
sein. Insbesondere, wenn die Testsuite auf einer langsamen
Zielplatform lange läuft und manuelle Interaktion erfordert.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.