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

Volker Grabsch vog at notjusthosting.com
Mi Jan 24 15:59:54 CET 2007


On Thu, Jan 25, 2007 at 12:29:59AM +1100, Peter Ross wrote:
> Nun, mein Problem mit Deinen Ausfuehrungen dazu ist, dass ich immer noch 
> keine Definition des Begriffes Changesets habe:-(

Sorry, hab keine gute Definition parat gehabt, sonst hätt ich sie längst
zitiert.

Was ich aber weiß, ist dass GIT, Mercurial und Darcs in etwa das gleiche
meinen, bis auf Implementierungsdetails.

Subversion hingegen dehnt diesen Begriff tatsächlich aus. Und zwar so
weit, dass er gerade auf Subversion passt, aber noch nicht ganz so
weit, dass er auf CVS passt.

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

Ja, das klingt gut. Obwohl es jetzt so stark an verteilten VK orientiert
ist. Ich würde sagen, die Changesets müssen sich auf andere Branches
anwenden lassen. Ob der im selben Repository existieren muss oder nicht,
ist erstmal nebensächlich.

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

ACK. Darum geht es auch gar nicht.

Natürlich ist jeder Merge etwas Arbeit. Aber die Übersicht, was wie mit
wem gemerged werden muss, die sollte der Benutzer nicht im Kopf haben
müssen. Das schränkt nämlich ein.

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

ACK.

Deshalb finde ich den Ansatz von Mercurial (gegenüber Darcs) recht
sinnvoll: Jeder Merge braucht einen extra Commit. Das heißt, wenn du
zwei Branches mergest, ist der "Merge" ein weiterer Knoten, der die
beiden Entknoten der Branches als Abhängigkeiten hat.

Das heißt, selbst wenn es beim Merge keinen Konflikt gibt, *ist* es
eine extra Aktion, die du erst committen musst. Damit ist klar, dass
es niemals nebenher "unter der Haube" passieren kann, wie es z.B. in
Darcs gang und gäbe ist.

Dem Anwender wird unter Mercurial bewusst gemacht, dass er sich noch
im Merge befindet, und erst noch testen sollte, bevor er den Commit
macht.

Dieser Commit (oder Changeset :-)) bedeutet dann, dass dieser Merge
erledigt ist, d.h. andere werden sich dieser Merge-Changeset direkt
von ihm herunterladen und eben gleich ein sauber aufgelöstes Merge
vorfinden.

Ich finde, das ist auf diese Weise genau richtig gelöst, selbst wenn
es zunächst wie eine Einschränkung von Mercurial aussieht, dass
konfliktfreie Merges trotzdem ein extra Commit brauchen.


Auf dein Beispiel gehe ich nicht weiter ein, die Problematik ist klar
und ich bestreite sie auch gar nicht. :-)  Das ist aber ein
grundsätzliches Problem, das dir keine Versionskontrolle der Welt
abnehmen kann.

Obwohl Darcs so tut, als könnte es das halbwegs. Darcs hat aber
dadurch dann wieder Stärken, wenn du ein großes Projekt hast und
für dieses ein paar kleine, weitestgehend unabhängige, Patches
entwickelst. Dann wäre Mercurials Verhalten etwas nervig.

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

Genau.

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

Ja.

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

Fuzzy-Logik ist ein interessantes Thema, dem ich in meinem Studium
vor kurzem schon zum zweiten Mal begegnet bin.


Viele Grüße,

    Volker

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



Mehr Informationen über die Mailingliste linux-l