[linux-l] Re: VCS

[Steffen Dettmer]

* Volker Grabsch wrote on Sat, Apr 22, 2006 at 09:51 +0200:
> On Thu, Apr 20, 2006 at 11:27:34PM +0200, Steffen Dettmer wrote:
> > 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. 
> 
> Automatisierte Tests können sowieso nicht alle Qualitätsmerkmale
> feststellen. 

Klar, und Testen kann man sowieso nur die Anwesenheit von Fehlern und
nur von einigen, klar.

> Sie sind eine sehr gute Hilfe, aber "Handarbeit" wird immer nötig
> sein. Zumal aus der Handarbeit meist erst die Ideen für (weitere)
> automatisierte Tests kommen.

Ja, nebst anderen Vorteilen. Ich mag sowas wie test-driven development
eigentlich ganz gern. Am liebsten entwickel ich unittest und code
nebeneinander.

> Aber hab ich dich richtig verstanden? Ihr könnt dort nichtmal
> compilieren, ohne die Maus schubsen zu müssen? Das ist ja schrecklich.

Im Moment nicht für die Zielplattform, richtig. Ich persönlich arbeite
immer erst unter Linux, aber das ist wohl Geschmackssache. Glücklich bin
ich jedenfalls solange, solange ich noch unter Linux arbeiten kann.

Wir kommen jetzt endlich dazu, dass building via automake auch für die
Zielplatform anzugehen (ist alles in allem gar nicht einfach!).

> > 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.
> 
> Hey, jetzt musst du aber konsequent bleiben. :-)

:-)

> Zuerst erzählst du mir, wie ungeheuer, ungeheuer wichtig es ist, das
> Repository immer im sauberen Zustand zu halten. Deshalb mein
> Vorschlag, wie man das sicherstellen kann.

Ja, OK. Aber dennoch "Disziplin muss vom Entwickler kommen", Ausnahmen
bestätigen die Regel ,)

> Wenn der compilierfähige Zustand doch nicht so wichtig ist, dann
> lässt man das eben.

Es ist wichtig - und es gibt Ausnahmen. Und vor allem Grenzen der
Realisierbarkeit, klar.

> Oder man deaktiviert für kurzfristige Hacks die Hooks, einfach das
> Hook-Script umbenennen, oder auskommentieren.
> 
> Ich verstehe daher nicht, wo hier das Problem liegt.

Ja, OK, könnte man natürlich machen.

> ACK. Das ist auch meine persönliche Erfahrung. Zumal ich nicht bei jedem
> Sch... gleich versioniere. Manche Dinge fangen klein an, und werden
> völlig überraschend größer, und mehr Features werden benötigt, u.s.w.
> 
> Irgendwann wird das "kleine Script" in mehrere Dateien aufgespaltet,
> die immer noch anwachsen. Das ist ungefähr der Zeitpunkt, ab dem ich
> ein eigenes Verzeichnis dafür spendiere, und darüber ein SCM jage.

Ja, z.B. Wir haben eigentlich fast alles im CVS, und verschieben es
dann. Ich nehm sogar gerne das, was wir "exp module" nennen, also
experimentelles irgendwas, wird später in ein anderes Modul übernommen,
da hat man dann die riesen-diffs auch nicht mit im Weg :) Obwohl ich da
auch gern ,v Files kopiere, weil ich persönlich die diffs doch lieber
habe weil man weiss ja nie :)

> > > (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 denke an kleinere Änderungen. Sagen wir, ca. 1-2 Stunden Arbeit.
> Bei Kommentaren oder Korrektur von Rechtscheibfehlern, oder kleinen
> Bugfixes manchmal auch nur das Ergebnis von 5min Arbeit.
> 
> Aber eben kleine, abgegrenzte Teilschritte.

Ahh, OK. Sowas geht mit CVS aber auch noch ganz gut, finde ich.
Zumindestens finde ich das, weil ich nix anderes kenne :)

> Bei mir sind das nur selten mehr als 50 Zeilen, aber Python-Code. Je
> nach Programmiersprache und Zweck (und der Eignung der Sprache für den
> Zweck) kann das natürlich auch mehr Code sein, der eine bestimmte
> Teilaufgabe erledigt.

Ja klar, eine neue Funktion oder sowas ist ja meist unproblematisch.

> Und diese Bruchstücke lassen sich natürlich viel leichter verwalten.
> Das Changelog der Versionskontrolle ist damit natürlich nur noch für
> Entwickler brauchbar, aber ein "zusammengefasstes Changelog" sollte
> IMHO sowieso von Hand geschrieben sein. Selbst bei größeren Änderungen
> pro Commit wird man noch zusammenfassen müssen.

Seh und mach ich genauso.

> > 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. 
> 
> Falls du damit auf die Hooks hinaus willst: Ja, einen 100%-pass der
> Unittests sollte man besser nicht für einen Commit fordern. Compilier-
> barkeit vielleicht eher.
> 
> Unittests in den Hooks sind eher für "fertige" Projekte sinnvoll, z.B.
> für freie Software, bei der mehrere Leute die Rechte zum einchecken
> haben.

Na wie gesagt, ich bin mir noch nicht sicher, ob man das technisch oder
"nur administrativ organisatorisch" fordern soll (sprich, schreibt man
es nur auf oder lässt man es wirklich prüfen).

> Auch bei CVS hindert den Studenten nichts daran, den ganzen Tag
> lang zu arbeiten und erst ganz zum Schluss hochzuladen. Das ist
> eine Frage der Absprache, nicht des SCM.

Ja genau, ein SCM löst kein Problem, was man bei einem Kaffee nicht
lösen kann. 

> Also von den Workstations würde sowieso Backups machen, es sei denn,
> es ist vereinbart, dass jeder alles, was er hat, spätestens am Ende
> des Tages ins SCM packt. Ohne solche eine Vereinbarung ist es immer
> möglich, dass lokale Änderungen nicht gesichert werden.

Na ja, da erfahrungsgemäss Platten sooo oft nicht ausfallen, kann man
auch mal einen Tag nicht einchecken. Allerdings besteht halt die Gefahr,
dass irgendjemand dreissig mal "einen Tag lang" nicht eincheckt - in
Folge :-)

> > 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).
> 
> Also, dann natürlich erst recht nicht!
> 
> Aber schonmal zu Hause ein anderes SCM verwenden, sei es Subversion,
> oder besser Mercurial bzw. GIT, das kann ich nur empfehlen. Erst wenn
> man im kleinen etwas ähnliches hochgezogen hat, sollte man es im
> großen anpacken.

Ja, klingt nach einer guten Idee. Würde da bloss nicht wissen, was nu
eigentlich und leider komm ich privat zu keinen Projekten mehr...

> Ich hab's mir durchgelesen. "flying fish" ist eine Vergewaltigung von
> Branches. Da bieten changeset-basierte SCM von vornherein ein besseres
> Konzept, um diesen Zweck zu erreichen.

Einigen wir uns auf Geschmackssache.

Logisch ist das im Prinzip ein Changeset.

> Zumal man dann auch flexibel nur Teile des Branches einweben kann.
> Oder ein Entwickler hat ein Feature, ein anderer kommt hinzu um
> ihn zu helfen, dann tauschen erstmal nur die beiden ihre Patches
> aus (sie bilden den "Branch"), und sobald es stabil ist, kommen
> ihre Patches (egal von wem, sind ja die gleichen) rein ins zentrale
> Repository.

Ja, machen wir mit CVS auch manchmal sowas. Mergt man sich mal zwei
Branches zusammen irgendwohin, um zu gucken, ob's überhaupt geht oder
so. Wenn man das dann einschätzen kann, kann mans dann dahin mergen, wo
man's braucht. Das wird mit CVS aber schnell fummelig. 

> Achso, du meintest das inhaltlich. Ja natürlich, das ist immr mit
> Risiken verbunden. Ich meinte, dass z.B. darcs sich merkt welche
> Patches von welchen abhängen, sodass es sicher feststellen kann,
> welche älteren Patches *überhaupt* nachträglich rückgängig gemacht
> werden können.

Na, dass ist ja dann auch nur ein CVS-reverting! In darcs mache ich ein
Changeset "Modul X refactorised". Kann ich dann wieder rausnehmen. In
CVS kann ich einen Branch machen. Kann ich dann wieder rausnehmen.
(sogar genau untereinander :)). Ist doch nix gross anderes, oder?

> Ob das Resultat noch lauffähig ist, ist natürlich eine andere Frage,
> IMHO wird das fast immer so sein. Aber gut, in großen Teams mag das
> anders aussehen.

Wir sind ein Team von 10-20 und da ist ein nicht-trivialer Revert der
nicht gleich gemacht wird selten ohne Anpassung kompilierfähig. Aber
natürlich i.d.R. nur Kleinigkeiten. Dazu muss man natürlich sagen, dass
man ganz kleine Sachen eh selten bis nie reverted, also 3 Zeiler oder
so, die korrigiert man dann meist gleich richtig.

> Mir ging es hier nur um die technische Möglichkeit. Und die ist z.B.
> nicht gegeben, wenn ein späterer Patch einige Änderungen des aktuellen
> Patches nochmal ändert. Solche patch-abhängigkeiten werden von Darcs
> automatisch erkannt und berücksichtigt.

In CVS gibt's einen Konflikt und man bastelt sich dann händisch im
Editor was zusammen.

> > > 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.
> 
> Darcs bietet dir nach und nach eine Liste von rückgängig-machbaren
> Patches. Da wählst du eine oder mehrere Patches aus, und gut ist's.
> UND: Diese Dinge werden nur aus dem Repository geworfen, nicht aus
> dem Arbeitsverzeichnis, d.h. die Änderungen sind nach wie vor vorhanden,
> tauchen nun aber als "loakle Änderungen" auf.

rückgängig-machbaren Patches?! Entscheidet das Tool, was ich reverten
darf, und was nicht?! Warum sind nicht alle Patches ückgängig-machbar?

Du verwirrst mich immer mehr. Gerade dachte ich, Ansätze zu begreifen
und nun bin ich wieder verloren :)

> Anders ausgedrückt: Das Arbeitsverzeichnis ändert sich bei dieser Aktion
> nicht.

Das ist ja auch blöd, wie teste ich dann, ob's geklappt hat? Ich möchte
doch kontrollieren, was dabei rauskommt, bevor ich das Repository
ändere?

> > 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.
> 
> Klar. Aber mit der Argumentation könntest du, wiegesagt, auch RCS
> nehmen. ;-)

Nein, da kann man nicht taggen, damit nicht wirklich reproduzieren :)

> > > 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.
> 
> Nee, nicht wirklich. ;-)

Doch, wirklich! :)

Technisch ist das ja auch so: für CVS ist das nur ne Folge von Patches,
also ja auch eine Zusammenstellung von Patches. Seh da den essentiellen
Unterschied immer noch nicht. Den einzigen Unterschied den ich sehe,
dass ich bei CVS zwei Punkten/Stände oder einen Branch benennen muss,
bei darcs aber "das zwischen" zwei Punkten benennen kann.

oki,

Steffen

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