[linux-l] Nutzt jemand Git?

[Volker Grabsch]

Steffen Dettmer <steffen at dett.de> schrieb:
> * Oswald Buddenhagen wrote on Mon, May 18, 2009 at 09:16 +0200:
> > On Mon, May 18, 2009 at 01:18:12AM +0200, Volker Grabsch wrote:
> > > Dass man das Mergen und ähnliches anderen überlassen kann, ist gerade
> > > eine der Stärken der DVCS.
> > >
> > vorsicht. das klappt nur, wenn man eine mehrstufige hierarchie hat wie
> > bei linux oder eine eine feingranulare partitionierung in kleinere
> > repositories wie xorg. ansonsten ist das mergen ein
> > ganz-oder-garnicht-prozess, der auf eine einzelne person zurückfällt.
> 
> 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.

    2) stabile Bereiche der Branches regelmäßig in den Trunk
       zu mergen (falls möglich).

Beides sind in den DVCS triviale Operationen. Mit SVN geht
es aber auch einigermaßen, vorallem sobald SVN endlich
Merges selbst verwalten kann.

Das Problem liegt in dem Fall also beim Entwicklungsmodell
und nicht bei den Tools. Warum sollte man erlauben, dass
sich ein Branch dermaßen weit vom Trunk entfernt? Wenn man
die technische Möglichkeit hat, mit wenig Aufwand häufige
Merges vorzunehmen, und diese nicht nutzt - selbst schuld.
Was nützt eine noch so gute Technik, wenn sie nicht benutzt
wird?

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

Das ist wie mit dem Debugging: Je später ein Fehler gefunden
wird, umso aufwändiger ist es, ihn zu fixen. Ergo lohnt es
sich, zusätzlichen Aufwand zu betreiben, um Fehler frühzeitig
aufzudecken.

> Beim Branch mergen kann es
> aber sogar vorkommen, dass man eine der drei betroffenen
> Implementierungen nicht kennt - oder auch keine davon.

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)

> Auch die Idee, einfach oft und in kleinen Schritten zu mergen,
> funktioniert nicht

Warum nicht? Was sollte einen daran hindern?

> 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". :-)


Gruß,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR