[linux-l] Re: VCS

[Peter Ross]

On Mon, 10 Apr 2006, Rocco Rutte wrote:

> * Volker Grabsch <vog at notjusthosting.com>:
>> On Sat, Apr 08, 2006 at 03:15:39AM +0000, Rocco Rutte wrote:
>>> * Volker Grabsch [06-04-05 15:27:27 +0200] wrote:
>
>> Darcs ermöglicht sogar, dass man sich alle "Hunks" (Änderungsstellen)
>> innerhalb der Dateien ansieht, und bei jedem "commit" (dort: "record")
>> auswählt, welche Hunks aus welchen Dateien man haben will. Das erleichtert
>> es ungemein, saubere Patches zu erstellen.
>
> Ich für meinen Teil verstehe den Sinn dahinter nicht. Klar, wenn man aus 
> einer Edit-Session für eine Datei zwei Commits machen will hilft es 
> vielleicht, aber es bei mir nicht die Regel.

Ich finde es immer gut, wenn nicht zuviele Aenderungen auf einmal comitted 
werden. Wenn's schiefgeht, dann ist es einfacher zu finden, welche 
Aenderung denn das bewirkt hat. Und man kann problemloser einen moeglichst 
befriedigenden Stand benutzen und muss, wenn Not am Mann und Stabilitaet 
gefragt ist, nicht gleich alles verwerfen.

Es kommt zum Beispiel vor, dass jemand etwas Neues schreibt und 
gleichzeitig z.B. eine C-Nullpointer-Abfrage einbaut, dummerweise mit 
einfachem statt doppelten Gleichheitszeichen.

Hinterher wird stundenlang der brandneue Code getestet, bis dann im 
Debugger das toetliche "=" erscheint.

Bei separatem Commit der Abfrage haette ein Auschecken der Vorversion 
gleich den Finger auf die Wunde gelegt.

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

(Ich selbst neige auch dazu. Das Werden eines Projekts zu kommunizieren, 
ist mir nicht angeboren, dazu muss ich mich zwingen).

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

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

So wird bei meinem Arbeitgeber gearbeitet, und es klappt ganz gut.

Gruss
Peter