[linux-l] Re: VCS

[Steffen Dettmer]

* Rocco Rutte wrote on Mon, Apr 10, 2006 at 15:26 +0200:
> Es ging um speziell um ein darcs-Feature. Die Situation: ich will Datei 
> foo.c komplett überarbeiten und habe das erst zu 50% geschafft. Und 
> jetzt kommt jemand mit einem simplen Fix, der Crashes (oder Panics in 
> Kerneln) oder so verhindert. Mit CVS oder subversion muss man da viel 
> Handarbeit anlegen (weil man lokal mglw.  schon viel geändert hat) bzw. 
> braucht gleich eine neue Workingcopy.
> 
> Bei darcs kann man wirklich nur die 1 Zeile committen und alle anderen 
> geänderten Zeilen/Dateien so lassen wie sind. Vorteil: man muss den Fix 
> nicht mergen (lassen).

Das ist wohl eine Frage, wie das Team arbeitet.

Würde in meinem Team einer mit sowas anfangen, würde ich ihm auf die
Finger klopfen, dass nur eingecheckt werden soll, was kompiliert. Das
weiss man bei einer Zeile nicht, vielleicht hängt die von einer zweiten
ab (wo der neue int deklariert wird oder so).

Ich persönlich arbeite gerne in kleineren Refactoring-Schitten mit
vielen commits, mehrmals täglich. Läuft Unittest, check-in. Passt ja
auch gut zu der Idee, pro logischer Änderung ein commit zu machen.
Andere (die meisten) arbeiten mit grösseren Änderungen. Oder auch in
verschiedenen Branches, weil man in der alten Version evtl. ein neues
Feature besser Testen kann oder so.

> Bei wirklich trivialen Änderungen, die Crashes verursachen, sollte das 
> auch in -current so schnell wie möglich rein. 

Warum, damit jeder den Crash hat? :-) SCNR.

> Außerdem sollte jede Änderung in -stable per merge aus -current kommen
> und dort die Testsuite überstanden haben und von mehr Leuten als einem
> selbst benutzt worden sein.

Ich finde die -stable / -current Terminologie doof. Dann lieber
Release-Kandidaten-Branches. Aber sicherlich Geschmackssache.

> Wenn ich in einem Teil an einer größren Überarbeitung arbeite und mit 
> einem Commit zum Beispiel eine API umschreibe, die andere Teile 
> brauchen, dann mache ich sowas in einer Branch, die erst dann nach 
> -current oder trunk/ zurückgeschrieben werden, wenn alle 
> offensichtlichen Sachen wieder gehen.

Ja, das gefällt mir, mach ich bei nach aussen sichtbaren (sprich
modul- oder libübergreifenden Änderungen) auch gern. Passt zum "flying
fish" Prinzip.

> Oder ich arbeite manchmal tagelang an etwas um zu merken, dass es 
> totaler Quatsch war. Da ist eine Extrabranch sinnvoll, weil ich dann 
> einfach die Branch lösche statt tonnenweise Revisionen aus -current 
> rückgängig zu machen.

Ja, und es geht einfach, weil in dem exp-Branch keiner was anderes
geändert haben sollte. Im trunk kann man selten "einfach so" reverten.

oki,

Steffen

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