[linux-l] Versionskontrollen (war: Warum gibt es keine einheitliche Dokumentation?)
Peter Ross
Peter.Ross at alumni.tu-berlin.de
Di Jan 23 01:02:39 CET 2007
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
Mehr Informationen über die Mailingliste linux-l