[linux-l] Versionskontrollen (war: Warum gibt es keine einheitliche Dokumentation?)
Volker Grabsch
vog at notjusthosting.com
So Jan 21 12:54:47 CET 2007
On Sun, Jan 21, 2007 at 12:05:37AM +0000, Peter Ross wrote:
> On Sat, 20 Jan 2007, Volker Grabsch wrote:
>
> > Versions-Basiert | Changeset-Basiert
> > ------------------------------------------
> > RCS | Darcs
> > CVS | GIT
> > Subversion | Mercurial
> > | Arch
> > | Monotone
>
> Da setzt meine Irritation ein..
>
> Ich sehe einen Unterschied zwischen Versionskontrollen, die lediglich
> Aenderungen je File speichern (RCS und CVS) und denen, die
> fileuebergreifend (mit "Changesets") arbeiten.
Ich weiß nicht, wo du das gelesen hast, aber "Changeset-basiert"
wird nirgends mit "Datei-übergreifend" gleichgesetzt.
Außerdem werden "chageset-basierte VK", "patch-basiert VK" und
"verteilte VK" oft synonym verwendet.
Wie du auf diese andere Begriffs-Definition kommst, weiß ich nicht.
Auf welcher Webseite / in welchem Buch hast du das aufgeschnappt?
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.
Der Einfachheit halber lass uns bitte bei dieser gängigen Definition
bleiben. Natürlich könnten wir auch vereinbaren, im folgenden Bäume als
Häuser zu bezeichnen, oder "ich" und "du" zu vertauschen. Aber was bringt
das denn, außer dass uns niemand mehr folgen kann, und wir irgendwann
selbst die Übersicht verlieren?
> > Versionen gibt es also auch in Changeset-basierten Versionskontrollen.
> > Nur ist dieser Begriff dort schwieriger zu definieren ... seine
> > intuitive Bedeutung ist aber klar: Jede Form, die der Code während
> > seiner Entwicklungszeit angenommen hat.
>
> Deshalb behilft sich CVS mit Tags, so dass man zumindest zu bestimmten
> Zustaenden fileuebergreifend zurueckkommen kann.
Ein anderes Problem, das spezifisch für CVS aufgrund seiner RCS-Geschichte
ist. Es lohnt daher nicht der Verallgemeinerung.
> Ich vermute, Du meinst mit Changeset Folgendes:
>
> Eine Software besteht aus den Dateien A, B und C und kann rote Kreise
> malen.
>
> Zwei Leute bekommen den Auftrag:
>
> 1.) das auch gruene Kreise gemalt werden koennen (dazu muss er File A und
> B veraendern, und deklariert die Aenderungen als sein Changeset)
>
> 2.) es sollen auch rote Ellipsen darstellbar sein (erfordert Aenderungen
> an B und C)
Ich stimme dir zu. Mit "Changeset" meinte ich genau das.
> Am Ende haette man gern beides (und vielleicht auch gruene Ellipsen), also
> muss irgendwo gemergt werden.
>
> Ohne explizite Changesets wird man mit Subversion z.B. branchen, und zum
> Schluss muss man das mergen (oder "backporten")
>
> Mergen muss man das auch, wenn es Changesets gibt..
Genau. Das Problem des Mergens ist prinzipieller Natur und hat erstmal
nichts mit Versionskontrollen zu tun. Mit "diff3" bzw. "patch" bzw. "merge"
kannst du auch ohne VK mergen. Kann man, muss man aber nicht. :-)
> Wenn man Subversion nicht gebrancht hat, wird man beim Einchecken merken,
> dass einer von beiden schneller war.. also muss auch hier gemergt werden.
>
> Aber im Grunde laeuft es alles auf das Gleiche hinaus - zwei Leute haben
> eine Datei veraendert, und das muss synchronisiert werden.
Genau. Anders gesagt:
Wenn es ein zentrales Repository gibt,
und jeder Entwickler vor jedem Commit mit dem Repository synchronisiert,
und jeder Entwickler jeden Commit sofort hochlädt,
dann gibt es keinen Unterschied zwischen zentralen und verteilten VK.
Dann entartet in einer verteilten VK der Changeset-Baum zu einer
einfachen langen Kette. Wenn du genau das und nicht mehr brauchst, dann
nimm Subversion.
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.
Klar, keine riesengroßen Einschränkungen, aber immerhin. Es reicht, um
Strategie wie Micro-Branchen komplett unbrauchbar zu machen, weil's in
Subversion einfach zu aufwändig wäre.
> Ich habe keine ausgiebigen Erfahrungen mit Dateien auf der "rechten Seite"
> Deiner Tabelle oben (nur Checkouts aus GIT), aber ich denke, das
> grundlegende Synchronisationsproblem ist bei allen aehnlich bei
> Subversion,
Nein, Subversion macht sich das Synchronisierungs-Problem besonders
leicht, weil es vereinfacht gesagt vor jedem "commit" ein "update" verlangt.
Branches werden von Subversion im Vergleich zu CVS relativ elegant
gehandhabt. Aber im Vergleich zu den verteilten VK ist Subversion
verdammt umständlich.
Dezentrale VK sind darauf ausgelegt, asynchron arbeiten zu können. Mehr
Anspruch an die VK, aber viel weniger Stress für die Benutzer.
> sie unterscheiden sich evt. lediglich in der Eleganz, dieses
> zu automatisieren (was immer ein Risiko bleiben wird - es sei denn, dieser
> Prozess besitzt soviel Intuition wie ein guter menschlicher Entwickler..)
Nicht nur. Auch die internen Datenstrukturen sind anders gestaltet.
> Manchmal scheint mir, dass unterschiedliche Dinge eher mit
> unterschiedlichen Begriffen um sich schmeissen, und dann wird es als
> "Neuheit" definiert.
Das trifft auf VK nicht zu. Dann hätte jede VK ihren eigenen "allgemeinen"
Namen. Außerdem reden wir hier von gerade mal zwei Begriffen.
> 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, implementieren
aber immer noch nur einen Bruchteil der verteilten VK. Selbst "svk", das
Subversion um gewisse Offline-Funktionalitäten erweitert, verdient nicht
wirklich den den Namen "verteile VK", auch wenn sie sich selbst gern so
bezeichnen.
Viele Grüße,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Mehr Informationen über die Mailingliste linux-l