[linux-l] Re: VCS

[Steffen Dettmer]

* Volker Grabsch wrote on Sat, Apr 15, 2006 at 14:20 +0200:
> On Fri, Apr 14, 2006 at 11:30:34PM +0200, Steffen Dettmer wrote:
> > 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.

Nein, es ist kein leichtes. Zunächst haben wir die eigentliche
Bauplattform nur für Windows (mit GUI, nix Kommandozeile) und können die
interessanten Tests gar nicht starten, weil man diese embedded devices
gar nicht so ohne weiteres laden kann. Klar, könnte man theoretisch
machen. 

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

Aber wenn das nicht kompiliert, KANN man dann nicht mehr
einchecken? Aber vielleicht ist es dieses einmal wichtig, weil ich mit
dem configuration und build manager und überhaupt dem gesammten Team
alle Details abgesprochen habe. Na ja, hat halt alles Grenzen.

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

Ich glaube, in "frühen Phasen", wo sich halt soviel ändert, muss man gar
nicht so genau die Übersicht haben. Aber Du hast natürlich Recht, "es
hängt davon ab" usw :)

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

Warum immer "Patches"? Ist die tägliche Arbeitsleistung eines
Vollzeit-Entwicklers jeweils ein Patch, der dann auch mal tausend Zeilen
haben kann, oder meinst Du eher begrenzte Änderungen?

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

Wenn ich einchecke, gehen in der Regel (!) mindestens die unittests, die
vorher liefen. Aber erstens nicht immer, weil vielleicht durch eine
Modulneuimplementierung eine Teilfunktion noch fehlt oder Fragen offen
sind - dann zeigt der Unittest das sehr schön. Zweitens laufen die
unittests dann auf der gerade benutzten Platform, bei mir meistens SuSE
SLES8, aber nicht unbedingt auf anderen, weil bei SuSE 7.0 autoconf-1.4
das Makefile.am nicht mag und für die embedded Platform das project-file
nicht angepasst wurde und dem ARM-Compiler ein cast fehlt - oder irgend
sowas. Da man nur eine ausgewählte Platform bei sowas testen kann, hilft
das IMHO nicht wirklich weiter (es sei denn, sie ist 100% gleich der
Zielplatform, falls es sowas gibt).

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

Ja, das ist schon klar, seh ich auch so. Wir tragen z.B. auch die
Trouble-Ticket-Nr. mit in die commit-Message ein (jedenfalls
theoretisch) usw.

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

Für kleine Bugfixes ist es ja egal, da könnte man RCS nehmen :-) Sind ja
oft Sachen, die sich hinziehen, manchmal Tage, weil Fragen geklärt
werden müssen oder refactorsierungen schwierig zu testen sind (oder zu
machen oder oder). Für die wichtigen Branches ein Arbeitsverzeichnis
macht oft Sinn.

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

Dann muss aber erstens jeder Entwickler aufpassen (bei uns ist das
SCM-fachliche Verständnis im Team recht unterschiedlich, und ein Student
sollte IMHO nix "lokal machen und später einchecken", weil ich es dann
nicht reviewen kann) und zweitens muss man dann Backups von den
Workstations machen, oder?

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

Ja, klingt interessant und spannend, hat sicherlich auch Vorteile. Und
natürlich Nachteile. Aber wie auch immer, ich kann mir hier nicht so
recht vorstellen, dass die Vorteile den teuren Umstieg von CVS aufwiegen
würden. Was vermutlich zum Grossteil an meiner CVS-Fixierung liegt, da
ich kein anderes SCM kenne (RCS belächeln wir hier mal nicht).

> Ist auch ein Weg, hängt natürlich

hängt? Davon ab? :-)

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

"Prinzip" war wohl bissel hochgegriffen; der Begriff scheint eine
Erfindung des CVS Buches [1] zu sein:

http://cvsbook.red-bean.com/cvsbook.html#The%20Flying%20Fish%20Approach%20--%20A%20Simpler%20Way%20To%20Do%20It

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

Ich glaube das nicht. Wie soll das funktionieren? Mit einem "diff" tool,
dass C Quelltext gramatikalisch analysiert oder wie? Der erste führt ne
neue Variable ein, der zweite initialisiert sie nicht direkt, sondern
über eine refaktorisierte Funktion, der dritte benennt sie um und der
vierte baut eine Prüfung und ein logstatement ein. Wie willte jetzt die
zweite Änderung (und nur die) reverten?!

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

"unabhängig"... Na, /dann/ kann CVS das auch. Da reverted man über ein
Datum, ein Tag (oder alt zwei) oder notfalls über Revisionsnummern (oder
commit-Ids oder wie auch immer das SCM sowas nennt) einfach per
textueller zeilenweisen Patcherei, klar. Gut, bei CVS muss man leider
händisch taggen und diverse andere Nachteile machen sich breit, gerade
bei weit verstreuten Änderungen, aber /wenn/ man das denn mal braucht,
kriegt man es hin.

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

Ja, OK, das ist bei CVS ja (mit etlichen Buch füllenden Einschränkungen)
auch in etwa so.

oki,

Steffen

[1] Open Source Development with CVS, 3rd Edition, by Karl Fogel and Moshe Bar
    http://cvsbook.red-bean.com/cvsbook.html

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