[linux-l] Re: VCS

Sa Apr 22 09:51:03 CEST 2006

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

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

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

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.

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

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.

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

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

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.

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.

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

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.

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

Es ist ja nur eine Möglichkeit. Aber wenn ihn das dazu motiviert,
kleinere Schritte zu versionieren, und er hochlädt, sobald eine
bestimmte Teilaufgabe abgeschlossen ist, dann ist das doch auch
super.

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.

> und zweitens muss man dann Backups von den
> Workstations machen, oder?

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.

Das gilt für jedes SCM, egal ob CVS, Subversion oder Darcs.

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

Sicher. Eine native Unterstützung von Branches (hat Darcs glaub ich
nicht, aber GIT) im SCM ist natürlich auch was schönes. Jenachdem worum
es geht.

> 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, 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:
[...]

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.

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

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.

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.

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.

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

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

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

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

Viele Grüße,

    Volker

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