[linux-l] Re: VCS

[Volker Grabsch]

On Fri, Apr 14, 2006 at 11:30:34PM +0200, Steffen Dettmer wrote:
> * 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).

Das eine widerspricht dem anderen nicht.

Zum Beispiel ist es ein leichtes, das Repository mit Hooks zu versehen,
der z.B. ne Testsuite startet (und vorher natürlich den Compiler).
Gibt es Probleme, wird der Patch nicht akzeptiert.

Jemand, der sich also bei der einen Zeile geirrt hat, wird diesen
Patch nicht ins große Repository reinbekommen.

Das ist auf jeden Fall besser, als wenn mehrere viele Sachen auf einmal
reingestellt werden. Denn in diesem Fall sind die Patches nicht mehr
übersichtlich.
(Sonst könnte man auch argumentieren, dass jeder Spaghetti-Code
akzeptabel ist, solange er die Testsuite passiert. Diese Abnormitäten
will man natürlich nicht, und kleine, leichtgewichtige Patches sind
ein guter Weg dorthin.)

> Ich persönlich arbeite gerne in kleineren Refactoring-Schitten mit
> vielen commits, mehrmals täglich. Läuft Unittest, check-in.

Wieso nicht andersrum? Ich meine, klar lässt jeder Entwickler ständig
Unittests laufen, aber die komplette Testsuite, um nochmal sicher zu
gehen, könnte auch gleich das Haupt-Repository übernehmen.

> Passt ja
> auch gut zu der Idee, pro logischer Änderung ein commit zu machen.

ACK. Und deshalb will ich nicht, dass ein Bugfix und ein Feature
gleichzeitig committed werden, bloß weil beim Auftrennen ein Fehler
passieren *könnte*.

Die Frage ist, wie man das abfedert, und Hooks kann man auch in
das eigene Repository einbauen ... ich mache (weil's sich anbietet)
nebenbei einen Bugfix, wähle nur diese Änderung aus und "record"e
nur diese (bei mir lokal), dann rennt lokal ne Testsuite rüber und
haut mir auf die Finger. Gut, dann nehme ich noch nen dritten Hook
hinzu, den ich vergaß, und nun wird es "record"ed.

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

Klar, die Freiheit hat man immer. Aber für jeden kleinen Bugfix oder
gar Doku-Korrektur ein extra Arbeitsverzeichnis?

Man sollte auch umgekehrt die Freiheit haben, die Arbeit an einem
Arbeitsverzeichnis in mehrere kleine Schritte aufzuteilen.

In Darcs (und anderen changeset-orienterten VCS) kann man lokal
erstmal verschiedene Änderungen aufzeichnen, und dann mehrere davon
auf einmal ins Haupt-Repository hochladen. Das ist z.B. sinnvoll,
wenn jemand an einem bestimmten Feature arbeitet, das aber noch
instabil ist. Erst, wenn es stabil ist, wird's hochgeladen.

So ist der "Branch" quasi beim Entwickler (sein
Respository/Arbeitsverzeichnis ... ist ja in Darcs dasselbe),
und der "Merge" geschieht durch Hochladen seiner Patches ins das
Haupt-Repository.

Ist auch ein Weg, hängt natürlich

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

Natürlich. Deshalb redet man ja auch nur von "Branches". Wie du
deine Branches logisch aufteilst, da lässt dir jedes VCS freie Hand.

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

Das genau ist das "flying fish" Prinzip? Wenn ich danach google, krieg
ich alles mögliche, nur kein Entwicklungs-Konzept.

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

Doch, schon. Aber nur in Changeset-basierten VCS.

Darcs z.B. kann das. Aber nur, wenn die darauffolgenden Patches unabhängig
sind. Bei neuen Features ist das aber i.d.R. der Fall.

So kann man dann die verschiedenen Branches einfach als verschiedene
Zusammenstellungen von Patches (d.h. changesets) betrachten.


Viele Grüße,

    Volker

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