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

Peter Ross Peter.Ross at alumni.tu-berlin.de
So Jan 21 01:05:37 CET 2007


Hi Volker,

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.

Erstere haben Probleme, fileuebergreifend rueckwirkend einen Zustand 
darazustellen.

Der zustand sind die Versionen, nach Aenderung eines Changesets, so ist 
auch diese Aussage von Dir sinnvoll:

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

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)

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

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.

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

Manchmal scheint mir, dass unterschiedliche Dinge eher mit 
unterschiedlichen Begriffen um sich schmeissen, und dann wird es als 
"Neuheit" definiert. Erinnert mich an meine Uni-Vorlesung 
"Softwaretechnologie", wo ich nach einer Weile gesagt habe, dass 
verschiedene verglichene Entwicklungsmethoden unterschiedliche 
Nomenklatura sind, um das selbe mal mit roten Kreisen und gruenen Pfeilen 
und dann mal mit gruenen Kreisen und roten Pfeilen darzustellen.

Widersprochen hat mir zwar keiner, auf Grund meiner Ignoranz, das 
ernstzunehmen, habe ich dann in der Pruefung auch nur 'ne Vier bekommen;-)

Zurueck zu Deinen Versionskontrollen: haben nicht alle Baumstrukturen, und 
wenn Mergen dazukommt, gerichtete Graphen?

Das die dann intern zur besseren Handhabung dazu aufgebrochen werden, 
aendert am Ergebnis doch nicht allzuviel (sollte dem Anwender verborgen 
sein) .. oder?

Anyway, zurueck zur Realitaet. Ich habe sie leider noch nicht eingecheckt, 
sonst koennte ich zum Zustand, bevor mein Toast verbrannt ist, 
zurueckkehren..

Es gruesst
Peter


Mehr Informationen über die Mailingliste linux-l