[linux-l] Nutzt jemand Git?

[Steffen Dettmer]

* 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. viele
Konflikte bekommt (die nicht trivial lösbar sind, weil
z.B. geänderte Funktionen nicht mehr existieren) und das drei
Tage dauert, sollte man einen temp branch zum Mergen in Erwägung
ziehen.

> da aber niemand den ganzen code kennen kann, muß der "merge
> monkey" öfter mal rumfragen, wie nun gemerged werden soll.

Ja, und welche Teil-Funktionalitäten vielleicht auch komplett neu
implementiert werden müssen, weil der `alte' Ansatz überhaupt
nicht in den `neuen' Branch paßt.

> zumindest gilt das für "globales" merging, wie z.b. den
> stable-branch in master einpflegen.  natürlich könnte man von
> den leuten einfach fordern, daß sie wie früher nach jedem
> commit in den stable-brach gleich nach master mergen, aber das
> ist irgendwie "nicht git".

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.). Dann ändert man
eine Funktion einer bestimmten Teillogik in einem Branch, die es
in neueren Branches vielleicht überhaupt nicht mehr gibt, ja, es
kommt vor, dass die gesamte Teillogik ersetzt werden mußte, weil
neue Anforderungen nicht gut genug erfüllbar waren.

> > Meine Erfahrung ist, dass man eher bei SVN gezwungen ist,
> > irgend- welche Konflikte zu lösen, weil man sonst
> > keinen Commit machen darf. Dabei ist es "Zufall", wer
> > den Konflikt letztendlich lösen muss - es ist nicht der mit
> > der meisten Ahnung, sondern der, der zufällig als zweites den
> > Commit absetzt.

Meiner Erfahrung nach sind die Konflikte, die man bekommt, weil
man vor dem einchecken updaten muß und jemand anders im gleichen
Branch zeitnah die gleiche Stelle geändert hat, im Prinzip immer
trivial. Oft ist die selbe Sache gemacht worden (liegt ja in der
Natur der Sache). Da hat man dann auch deshalb kein Problem, weil
man die geänderte Stelle ja kennt. Beim Branch mergen kann es
aber sogar vorkommen, dass man eine der drei betroffenen
Implementierungen nicht kennt - oder auch keine davon. Auch die
Idee, einfach oft und in kleinen Schritten zu mergen,
funktioniert nicht und ein Merge oder Konflikte heißt noch lange
nicht, dass das Ergebnis compiliert oder gar funktioniert.
Ist dann schon iritierend, wenn nach dem Mergen unbenutzte
Variablen oder gar unbenutzte Funktionen angewarnt werden...

oki,

Steffen

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