[linux-l] Re: VCS

[Rocco Rutte]

* Peter Ross <Peter.Ross at alumni.tu-berlin.de>:
>On Mon, 10 Apr 2006, Rocco Rutte wrote:

>>NACK. Ich mache bei allen nicht-trivialen Änderungen 
>>Branches und manchmal auch Tags (was ja unter subversion das 
>>gleiche ist), und committe größere Änderungen per merge dann 
>>"irgendwann".

>Hoffentlich nicht wirklich "irgendwann", sondern bald.

>Mit "Eigenbroetlern" zu arbeiten, die erst ein halbes Jahr 
>die perfekte Loesung ausknobeln, und sie dann ploetzlich 
>geballt der Menschheit vorwerfen, habe ich schlechte 
>Erfahrungen.

S.u.

>>Ich mache kaum noch etwas "Live" in trunk/, weil es 
>>passiert, dass Sachen nicht funktionieren und dann ist es 
>>gerade im Team schlecht, wenn nichtmal mehr trunk/ halbwegs 
>>geht. Dann sind alle blockiert bis "jemand" trunk/ wieder 
>>repariert hat.

>Ja, das ist so..

>>Oder man sitzt gerade an einer größeren Änderung und jemand 
>>kommt mit einem einfachen Fix, der schnell rein muss (ich 
>>weiss, darcs und hunks).

>Dafuer gibt es doch Branches wie -stable und -current oder 
>so. In -stable wird behutsam gearbeitet und alles sollte zu 
>annaehernd jedem Zeitpunkt funktionieren, da kann dann auch 
>"der schnelle Fix" rein.

(Ich mag FreeBSD auch ;-)

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

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

>-current ist nie totwichtig, da darf man warten, bis es 
>wieder geht, und es braucht keine schnellen Fixes.

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.

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.

   bye, Rocco
-- 
:wq!