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

[Peter Ross]

On Mon, 22 Jan 2007, Steffen Dettmer wrote:

> CVS steht doch nicht mit RCS auf einer Stufe. Verteufelt das jetzt mal
> nicht, bloss weils kein HTTP kann. SVN ist doch fast das gleiche. Gut,
> bei CVS benutzt man Revisionsnummern eigentlich kaum, bei SVN braucht
> man die zum mergen...

Nein. CVS und SVN unterscheiden sich _grundlegend_ darin, dass Du bei 
einem fileweise Revisionsnr. hat, waehrend Subversion die Revisionsnr. 
repositoryweit haelt.

Daher ist es mir (ohne tagging) moeglich, jeden Zustand des 
Gesamtrepositories (und so logisch zusammengehoeriger Dateien) 
wiederauszuchecken.

Bei CVS weiss ich nicht, dass logisch a.h (Rev. 1.4) zu a.c (Rev. 1.23) 
gehoert. Das sehe ich hoechstens an Kommentar oder Datum der Aenderung 
(beliebtes Ratespiel, btw).

> WAS? Gibt doch auch svn diff -r und so?

Ja, Wie gesagt, ich bin kein Experte und nutze derzeit nur Subsets der 
verfuegbaren Kommandos. Fuer meinen Bedarf reichts im Moment, wenn ich mal 
etwas Zeit hab (diddeldiddeldiddeldum;-), vertiefe ich das.

> Bei CVS kannste vorm einchecken ggf. noch fix branchen. Bei SVN nicht?

Ja. Aber das setzt voraus, das ich mitbekomme, dass meine Aenderungen mit 
einer anderen bereits eingecheckten in Konflikt geraet, so dass ich "in 
die Vergangenheit" branche.

(Leicht fiktives) Beispiel aus meiner Brandmauer: Ich habe ein 
Shellskript, welches eine Liste "$allowed" von erlaubten Verbindungen 
anlegt ("tcp:25 tcp:389").

Ein anderes Skript sourct dieses, und erweitert die Liste 
(allowed="${allowed} tcp:143")

Nun aendere ich das im ersten Skript, dass es auch noch eine Liste der 
Interfaces bekommt, durch die es hinein- und herauskann 
("intern:extern:tcp:25 intern:all:tcp:389")

Das checke ich ein.

Unabhaengig davon addiere ich im zweiten Skript
allowed="${allowed} tcp:143 tcp:995"

Das checke ich auch ein.

Es gibt keinen Konflikt fuer die Versionskontrolle - zwei Dateien wurden 
unabhaengig geaendert.

Doch durch Sourcen des ersten - nun geaenderten - Skripts, sieht allowed 
nun so aus:

"intern:extern:tcp:25 intern:all:tcp:389 tcp:143 tcp:995"

Autsch!

Ich _muss_ wissen, dass die erste Datei so geandert wurde, dass sie 
logisch fuer mich nicht mehr brauchbar ist, und an einem Punkt davor 
branchen.
 
> > Ein Vorteil von Deinem Changeset ist, dass ich den "Branch" auf ein Set 
> > von Dateien anwende. DAS ist mit Subversion so nicht moeglich.

Bei einem Changeset haette ich bei der ersten Aenderung vorher gesagt, 
Datei eins und zwei gehoeren logisch zusammen, und beim Einchecken der 
zweiten Datei haette mich die Versionskontrolle auf gemachte Aenderungen 
in der ersten Datei aufmerksam gemacht.

Schoen. Allerdings setzt es die Aufmerksamkeit des Entwicklers beim 
Definieren von Changesets voraus (ich muss wissen, dass die Aenderung in 
Datei eins Aenderungen in Datei zwei nachsichziehen muss).

Auch weiss ich nicht, ob es irgendeinen Weg gibt, um zu vermeiden, dass 
ich eine dritte Datei addiere, die auch $allowed aus Datei eins verwendet, 
und mich das Einchecken darauf aufmerksam macht, dass die vorausgesetzte 
Datei eins geaendert wurde.

Ich glaube nicht.

> Bei Changesets ist doch das Schöne, dass Du gar nicht branchen musst.
> Ein "branch" sind einfach nur zwei unterschiedliche Changesets mit
> gleichem Elternknoten. Dann kannste ein Changeset auch auf einen anderen
> Elternknoten anwenden (mergen).

Unterschiedliche Terminologie mit dem selben Effekt - nur eben moeglich 
fuer _logisch_ zusammenhaengende Teile des Repositories (die Dateien 
muessen nicht alle in den selben Subdirectories).

> *Diesen* seh ich dann nicht - oder es gibt ihn nicht.

Tja..

[Rocco]
> Von der menschlichen Logik sind Branches immer Graphen, aber fuer
> Subversion eben nicht. Es gibt da nur Pfade und Revisionsnummern. Dass
> du jetzt branches/xyz als eine Branch und trunk/ als Hauptlinie
> interpretierst, interessiert subversion nicht. Es gibt nur eine lineare
> Liste von Aenderungen an Pfaden, die mit einander etwas zu tun haben
> koennen aber nicht muessen.

branches/xyz und trunk _sind_ Branches und Hauptzweig in Subversion, der 
Rest ist Implementationsdetail (auch, dass Du vielleicht theoretisch 
Deinen Hauptzweig unter ../mondschein ablegen kannst)

Wie eine Versionskontrolle _intern_ aussieht (Datenbank, Verzeichnisbaum. 
Aenderungen speichernd oder aber den Gesamttext etc.) ist doch fuer den 
Anwender egal. Auch subversion hat Branches und eine (extern nutzbare) 
Graphenstruktur.

Ich bin nicht einmal hauptberuflich Entwickler, sondern SysAdmin (damit 
Nutzer und Admin von Versionskontrollen).

Aber es ist schon frustrierend, dass offensichtlich selbst Leute, die sich 
laenger damit beschaeftigt haben, oft sehr unterschiedliche Statements zum 
Thema Versionskontrolle abgeben.

Teilweise scheint es ein Problem zu sein, dass die Terminologie sich von 
Produkt zu Produkt unterscheidet, und Nebelbomben geworfen ("alles anders 
/ alles NEU!") werden.

Nach einer Weile fragt man sich, ob IT von Informatikern oder vom 
Marketing oder gar von Ideologen betrieben wird

Gruss
Peter