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

[Volker Grabsch]

On Sun, Jan 21, 2007 at 04:11:14PM +0100, Steffen Dettmer wrote:
> * Volker Grabsch wrote on Sun, Jan 21, 2007 at 12:54 +0100:
> > On Sun, Jan 21, 2007 at 12:05:37AM +0000, Peter Ross wrote:
> 
> > Es geht darum, dass nicht die Versionen im Zentrum stehen, sondern
> > die Änderungen *zwischen* den Versionen, auch Chagesets genannt. Darum
> > geht es. Changesets/Patches stehen im Mittelpunkt, nicht die Versionen.
> 
> Was übrigens bei CVS im Prinzip auch so ist, und so werden die Dinger im
> Repo auch gespeichert.
> 
> Ich denke, der Unterschied ist, ob ein SCM weiss, was wann wie gemergt
> wurde (HG, GIT, ...) oder nicht (CVS, SVN).

So habe ich das auch gemeint.
Dass intern Differenzen gespeichert werden, ist ja klar.

> > Besteht dein Feature hingegen aus meheren Changesets (mehreren
> > "commits"), musst du in Subversion einen Branch anlegen. Insbesondere
> > müssen beide Entwickler jeweils online sein, und der Branch muss
> > vorher explizit angelegt werden.
> 
> WAS?! Stimmt das so? Wäre ja noch ein extremer CVS Vorteil (dass man
> branches nicht /vorher/ anlegen muss - weil man vorher vielleicht gar
> nicht weiss, dass man einen braucht)! Aber glaube ich erstmal nicht. So
> schlecht kann SVN ja nu auch nicht sein.

Du hast mich missverstanden. Mit "vorher" meinte ich: "bevor du an dem
Branch arbeitest". Du kannst nicht einfach mit einem Feature anfangen,
das wie ein kleiner commit aussieht, dann mittendrin feststellen, dass
es in einen extra Branch rein sollte, und direkt in diesen neuen Branch
committen.

Sicher, irgendwie geht es, aber z.B. in Subversion nur umständlich:
Erstmal Versionsnummer deines letzten updates holen, diesen alten
Zustand in ein neues Verzeichnis kopieren (cheap copy), und in einer
(noch nicht "committeten") Arbeitskopie erstmal ein "svn switch" machen.

*Und* du brauchst erstmal Zugang zum Repository, kannst diese
Entscheidung "ich mache jetzt meinen privaten Branch auf" also nicht
schnell mal im Zug treffen.

> > Dezentrale VK sind darauf ausgelegt, asynchron arbeiten zu können.
> > Mehr Anspruch an die VK, aber viel weniger Stress für die Benutzer.
> 
> (funktioniert natürlich auch wieder nur gut, wenn man weniger eng
> zusammenarbeitet, sonst macht man alles doppelt, wenn man
> "microbranches" ausnutzt / übertreibt).

Nein, man hat höchstens ein paar mehr (triviale) Merges.

Dafür kann man unabhängig an verschiedenen Features arbeiten, selbst
wenn sie nur aus 2 oder 3 commits bestehen, also nicht wirklich einen
extra Branch rechtfertigen.

> Das schöne an dezentralen SCMs
> ist IMHO, dass man arbeiten kann, wie man will, mit allen Zwischenstufen
> bis hin zu zentraler Arbeitsweise.

ACK.

> Obwohl das sicherlich auch höhere
> Ansprüche an den Benutzer stellt.

Sich daran zu gewöhnen, jede Kleinigkeit zentral zu registrieren, ist
auch erstmal nicht ohne. Das ist auch ein Anspruch, den nicht jeder
Benutzer erfüllt. Meist führt es zu übergroßen Commits und ähnlichem.

Die Versionskontrolle wird nicht mehr zum Unterstützen des eigenen
Programmierern, sondern nur noch zum Abgleich mit den anderen
Programmierern benutzt. Man benutzt effektiv nur noch ein Merge-Tool,
keine Versionskontrolle. Das macht das Programmieren um einiges
umständlicher als es sein müsste.

Wird natürlich nicht so wahrgenommen. Die Ketten spürt man erst, wenn
sie einem kurz mal abgenommen werden. ;-)

> > > Zurueck zu Deinen Versionskontrollen: haben nicht alle
> > > Baumstrukturen, und wenn Mergen dazukommt, gerichtete Graphen?
> > 
> > Subversion nicht wirklich. Dort wird alles an einer Kette aufgefädelt.
> > Sicher, die Branches in Form von Kopien sind ganz nett, 
> 
> Ich finde eher, die Branches in Form von Kopien sind technisch eine
> Kette, aber logisch gar keine Kopien (sondern Branches) und sehr wohl
> gerichtete Graphen.

Ja, nur kriegt davon Subversion selbst nicht viel mit. Es kann mit
diesen "getunnelten" Graphen (getunnelt durch die lineare Struktur)
nichts anfangen, und besitzt nur rudimentäre Features, um diese zu
unterstützen.

Es "versteht" nicht wirklich, was dort passiert, im krassen Gegensatz
zu Mercurial & Co.

> Weiss eine "svn copy" überhaupt, von welcher Quelle es stammt?

Jain.

Die Versionsinformationen bleiben ja erhalten. Irgendwo findest du
in den Logs der einzelnen Dateien sowas wie "kopiert von ...".

Spätestens Merge-Quellen werden aber nicht mehr gespeichert. Deshalb
soll man ja immer brav die Revision-Nummer der Merge-Quelle bei jedem
Merge mit ins Commit-Log schreiben. :-)


Viele Grüße,

    Volker

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