[linux-l] Versionskontrollen (war: Warum gibt es keine einheitliche Dokumentation?)

Peter Ross Peter.Ross at alumni.tu-berlin.de
Mi Jan 24 14:29:59 CET 2007


Hi Volker,

On Wed, 24 Jan 2007, Volker Grabsch wrote:

> Ich habe "Changeset" nur in dieser einen Bedeutung kennengelernt,
> mit Ausnahme von Subversion, die ihn unbedingt auch für sich
> beanspruchen wollen.
> 
> Stellt man ganz hohe Ansprüche an diesen Begriff, versagen sogar
> Mercurial und GIT, dann ist nur noch Darcs changeset-basiert, weil
> man dort die Patches zu unabhängig wie nur irgendwie möglich um-
> arrangieren und verschieben kann.
> 
> Diese extreme Auslegung von Changeset hat Darcs aber nicht für
> sich als Begriff in Anspruch genommen.
> 
> Subversion macht das gleiche, nur dass es nicht besonders viele,
> sondern besonders wenige Anforderungen an ein Changeset stellt,
> und daher diesen Begriff aufweicht, um ihn auch für sich beanspruchen
> zu können. Meine Meinung.

Nun, mein Problem mit Deinen Ausfuehrungen dazu ist, dass ich immer noch 
keine Definition des Begriffes Changesets habe:-(

Ein Begriff, der lediglich durch die Entwickler einer Versionskontrolle 
selbst mit Inhalt versehen wird, ist IMHO eben nicht zur Klassifizierung 
geeignet.

Mangels Definition schaelt sich fuer mich auch erst nach laenglichem 
Disput heraus, was Du wohl mit "Changeset" meinst: eine Menge von 
Aenderungen eines Repositories einer verteilten Versionskontrolle, die Du 
auf andere Repositories anwenden kannst, und dort atomar erhalten bleiben.

> Schon allein das Kapitel "Best Practices for Merging" demonstriert
> eindrucksvoll, wie wenig entwickelt die Changesets in Subversion sind.
> (wozu "Best Practices" für etwas, das die Software eigentlich voll-
> automatisch machen soll?)

Ganz gewiss nicht elegant geloest, sicher. Vorallem fehlt eine 
automatische Zuordnung der Revisionen, die beim Mergen entstehen, zu den 
urspruenglichen Revisionen der Quelle (Anderung in trunk rev. 5 = 
Aenderung branch-4 rev. 17)

Das in einen Kommentar zu packen, ist ganz sicher keine geniale Idee. Wird 
aber so gemacht..

Auch wenn ich, wie ich schon erwaehnte, keine der verteilten 
Versionskontrollen ausgiebig verwende, bin ich sehr skeptisch, das es 
"vollautomatisches Mergen" geben kann, z.B. in dem Beispiel, was ich hier 
frueher erwaehnt habe.

Du magst wohl ein syntaktisch konfliktfreies Mergen hinbekommen, ob Du 
danach aber ein fehlerfreies Softwarepaket hast, steht in den Sternen, da 
Teile eines Codes immer mit anderem in einer Kontextbeziehung stehen. Du 
wirst immer testen muessen.

So mag ein Programm voellig fehlerfrei kompilieren, und doch abstuerzen. 

Zum Beispiel hast Du eine Funktion foo (a,b) geaendert, und darinnen wird 
a/b dividiert.

Ausserdem gibt es einen Aufruf in Deiner umgebung, die b=0 ausschliesst 
(implizit, weil die Werte durch die Umstaende nie null sein koennen).

Nun mergt Du das mit anderswo geaendertem Code, und da steht nun Deine 
schoene Funktion, und wird in diesem Kontext irgendwann mit b=0 
aufgerufen. Fubazu! (Furchtbarer Zustand!)

Das wird Dir ziemlich sicher keine Versionskontrolle verhindern..

Anyway, die Vorteile einer verteilten Versionskontrolle leuchten mir 
sofort ein.

Du traegst dann das Repository mit Dir herum, statt lediglich eines 
ausgecheckten Snapshots, und kannst so Deine Aenderungen feingranuliert in 
Deine lokale Kopie einpflegen, bis Du sie mit anderen Aenderungen 
zusammenfuehrst, und sie finden sich dort auch als eine Menge 
feingranulierter Aenderungen wieder.

Mit Subversion hast Du nur eine Zusammenfassung aller lokaler Aenderungen 
zu einer Aenderung im zentralen Repository, wenn Du sie dann eincheckst.

> > Naja, zumindest in Australien werden mehr und mehr "computer 
> > science"-Studiengaenge mit irgendwas mit "business" im Namen 
> > zusammengelegt, danach bleibt wahrscheinlich lediglich fuzzy logic uebrig.
> 
> Nein, Fuzzy-Logic ist ein vernünftiges Konzept, das kaum einer einsetzt.

Wirst Du jetzt fussy? Das war doch mein Job hier;-)

Gruesse in den Norden
Peter


Mehr Informationen über die Mailingliste linux-l