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

Steffen Dettmer steffen at dett.de
Sa Jan 27 14:59:29 CET 2007


* Volker Grabsch wrote on Thu, Jan 25, 2007 at 14:35 +0100:
> > >     $ cd ../trunk
> > >     $ hg pull -u  ../branch-A
> > >     $ hg merge
> > 
> > Was ist wenn ich mich verhaue?
> > 
>       $ cd ../trunk/directory1/
>       $ hg pull -u  ../../branch-A
>       $ hg merge
> 
> Das hat exakt den selben Effekt wie der erste Befehl.

Wieso, es packt mir die Files in das falsche Verzeichnis. Für HG müsste
es ja eigentlich so aussehen, als ob alle Files eine Ebene verschoben
wurden. Kann ja richtig sein, kann aber eben auch ein Fehler sein. Kann
doch das HG nicht wissen, oder? Vielleicht will ich das ja auch gerade
so haben. Muss man schon aufpassen. Irgendwie. Bei CVS muss ich keine
`URLs' merken (nur beim Auschecken). Das CVS weiss ja dann, "wo" ich
bin. Ich kann dabei natürlich directory1 nicht auf directory2 updaten.
Ist das nun eine CVS Schwäche oder ein Feature?

> > Ich rate mal es geht und es kommt ganz herrlich gequilrte Sch____ bei
> > raus ;)
> 
> Wie ich schon an der parallel laufenden SVN-Diskussion merke, bist du
> gerade mit Flamen beschäftigt. Hast du irgendeinen persönlichen Greul
> gegen Subversion, Mercurial o.ä.?

Flamen? mmm... Das war eigentlich nicht der Plan, nee. Vielleicht bin
ich ein bissel angespannt, weil es immer heisst, das CVS wäre so
schlecht und alles andere wäre besser, aber bis auf HTTP hab ich noch
kein wirlich unzweifelhaft *für meine Anwendung* erhebliches Feature
gehört (SVN ist IMHO sehr ähnlich zu CVS; HG und Co sind dagegen eine
Dimension höher).

Insbesondere bei SVN, was (jedenfalls glaube ich das noch immer, aber
vielleicht überzeugt mich ja noch jemand) nur mit einem einzigen
Repository funktioniert (bzw. dessen ganze Features funktionieren nur
dann).

Übrigens sind die CVS-Bugs, die ich kenne (und eigentlich alle nur bei
mehreren Repositories auftreten! was bei SVN ja schon mal gar nicht
geht!) hier nicht diskutiert worden. Aus der Diskussion, wie sie hier
stattfindet, muss doch dann folgen, dass CVS *für meine Anwendung* ideal
ist. Aber ich habe eher den Eindruck, dass man das gar nicht liest,
sondern einfach wieder antwortet, "nee, CVS ist Mist". So einfach kann
man sich das aber auch nicht machen :)

> > > Stimmt auch wieder. Obwohl *ich* wahrscheinlich eben dieser Kollege
> > > wäre. 
> > 
> > Prima, wären wir uns ja schon einig :)
> 
> Hey, hab ich da jetzt ausversehen einen ehrenamtlichen Support-Vertrag
> unterschieben?  D'OH!  ;-)

Ja klar ehrenamtlichen, wäre ja sonst teuer :-)

> > > > Ich würde bei "hg" erwarten, dass es eine Usage ausgibt. Brauchste gar
> > > > kein TAB :)
> > 
> > Na, ob ich nu enter oder tab drücke... Na egal.
> 
> Nee, das müsste heißen: Ob ich nun Tab drücke oder:
> * --help eingebe
> * Enter drücke
> * Pfeiltaste hoch drücke
> * das --help wieder wegstreiche (6-7 mal Backspace)
         (ESC-Backspace oder CTRL-W löscht ein Wort :))

die Usage kommt doch auch, wenn nicht --help? Wie auch immer, *sowas*
ist wohl kaum ein entscheidendes Feature. Und klar, wie Du schon gesgt
hast, man könnte ja die shell completion entsprechend einstellen.

> Wenn man schnell mal was wissen will, ist Tab ideal. Die andere Prozedur
> reißt einen erstmal aus dem aktuellen Gedanken heraus.

Ja, das mit dem rausreissen stimmt auch wieder. Nach dem Nachgucken
weiss man manchmal gar nicht mehr gleich, was man eigentlich wollte.

> > >     projekt-meinbranch/
> > >         [Projekt-Code]
> > >         modul1/
> > >             [Modul1-code mit projektspez. Änderungen]
> > >         modul2/
> > >             [Modul2-code]
> > >         modul3/
> > >             [Modul3-code]
> > 
> > Warum wird das Modul1-Repositor  davon niemals etwas mitbekommen?
> 
> Warum sollte es? Will man das?
> Die Änderung ist doch ein spezieller Hack für ein konkretes Projekt.

Na ja, gibt ja beides. Von den zehn Änderungen will man vielleicht acht
im "trunk" haben. Oder so.

> > Kann man da nicht "genauso nur andersrum" pullen?
> 
> Ich verstehe nicht ganz, was du meinst.
> 
> Ein Abgleich vom Projekt zum Modul ist nicht ratsam, dann landet
> nämlich plötzlich das ganze Projekt im Modul :-)

Warum denn das? Das versteh ich jetzt gar nicht. Das geht doch sogar
schon bei CVS? Wenn ich nur ein Unterverzeichnis mergen will, kann ich
das doch tun, insbesondere, wenn das Unterverzeichnis das
Stammverzeichnis/Modul (in CVS Terminologie) eines Repositories ist?

> Mir fällt gerade auf, dass dein konkreter Modul-Fall auch bei freier
> Software oft auftritt: Man macht erstmal selbst einen Fix, sendet
> den Patch zum Maintainer/Upstream und der pflegt es ein oder baut
> ne sauberere Variante dafür. Bis es soweit ist, bleibt der Hack
> erstmal im eigenen Projekt bestehen.

Ja, genau. Manche Patches will man aber rüber nehmen. Natürlich nicht
als diff|mail :) Bei CVS (also allgemeiner, bei zentralen) Repos ist das
immer einfach, weil man ja alle Änderungen kennt. Bei dezentralen kennt
man die erstmal nicht, aber der, der das dezentral geändert hat, könnte
ja die acht Änderungen da in einen Branch in das "höhere" einchecken.
Dann sieht das da der Maintainer. Also, wie auch immer das im Detail
ist. Kann ihm ja ne Mail mit der `URL' schicken, dann ginge das sogar
mit SVN. Mit CVS ist sowas natürlich besonders einfach, weil ein update
-r Branchname ja schon ausreicht, bei SVN ist Branchname nur komplexer
und bei HG ist Branchname ein Verzeichnisname (oder wie HG übers Netz
auch arbeitet, ist ja egal, jedenfalls also logisch das gleiche, ein
symbolischer Name).

Der Maintainer möchte das ja dann einfach mergen können, oder? Der
benutzt modul1 aber evtl. natürlich in einem ganz anderen Projekt. Oder,
wie in meinem aktuellen Fall, vorzugsweise in den wichtigen Branches
*aller* wichtigen Projekten. Ich hab also die Module bis zu 20-30 mal
auf verschiedenen buildsystemen ausgecheckt (in etwas weniger Projekten,
falls man ein Projekt in zwei Branches nur als ein Projekt zählt, aber
ist ja logisch auch wieder das gleiche).

> > hum, ich hoffe ich hab alles richtig verstanden. Ist für'n HG fremden
> > gar nicht so einfach...
> 
> ... für einen verteiles-VK-fremden ...  :-)
> Das Szenario würde in Darcs und GIT fast genauso aussehen.

Ja, stimmt, das ist der der essentielle Unterschied.

> > Also, ich soll die Sourcen nicht im projekt-Verzeichnis ändern? Sondern
> > in einem modul1-meinbranch? Wie teste ich das denn vor'm einchecken?
> 
> Du hast recht, das habe ich nicht bedacht. Okay, du brauchst Darcs,
> da ginge das aber wirklich. Da kannst du einzelne Changesets vom
> Projekt auch wieder zum Modul zurückschieben.

Das heisst, dass geht bei HG und GIT nicht? Kann doch nicht sein, oder?
Wozu hätte ich denn dezentrale Repositories, wenn ich die (einige der)
Änderungen nicht zurück in das Repository schieben kann, wo es herkam?
Oder auch von dem Repository aus "reinziehen" kann (was das gleiche sein
sollte, oder?).

Nu bin ich ganz verwirrt. Dachte, HG weiss gar nicht, welches Repo
welches ist? Wenn ich im Beispiel oben die Änderungen ins das orginale
rüberschiebe, könnte es doch sein, dass mein aktuelles ja das "Orginale"
ist, und ich Änderungen in eine Kopie schiebe? Mist, blöd ausgedrückt...
Ich meine, von den beiden Repositories ist doch keines "besonderer" als
das andere (dann wäre es ja auch "zentraler" und nicht "gleichberechtigt
daneben"), oder?

> Aber mit den üblichen Gefahren, dass deine Änderung irgendwie vom Hack
> abhängig ist, und in Modul1 ohne den Hack nicht mehr läuft.

Na ja klar, dass ein SCM die Änderungen nicht auf der Zielplattform
testen kann, ist schon klar :-)

> Alternativantwort: Du testest das Modul mit seinen Unittests. Dass
> es im Projekt funktioniert reicht eh nicht aus, du willst ja auch
> sichergehen, dass die Änderung die anderen Projekte nicht negativ
> beeinflusst, also brauchst du entsprechende Tests im Modul.

Ja klar, so ein Modul hat eigene unit tests. Ein Teil davon wird auch
funktionieren, wenn man es in "seinem" Projekt benutzt UND eine
entsprechende Plattform hat (linux, win/cygwin). Idealerweise natürlich
genau der Teil, der die verfügbaren Features testet (aber halt nur ein
Ideal :)). 

Aber das reicht ja nicht bei weitem nicht aus. Wenn unter SuSE Linux 8.2
die Änderung prima geht, kompiliert es mit einem anderen Compiler
(vielleicht sogar mit einem älteren oder neurem g++!) vielleicht gar
nicht und wegen Byteorderproblemen funktioniert eine kompilierende
Funktion nur auf i386 oder so.

(klar, 1: selbst wenn das alles geht, heisst das nix, 2: man
muss/kann/soll nicht alles vor'm einchecken testen, 3: mit Erfahrung
weiss man meist schon, wo die kritischen Punkte sind, 4: hat nur
bgegrenzt mit SCMs zu tun :))

> > In CVS würde ich es einfach in projekt-meinbranch einchecken. Das
> > Problem kriegt man natürlich nachher beim mergen.
> 
> Eben. Das geht mit verteilten VK auch, aber ich wollte ja die
> Probleme etwas eleganter lösen.

Aber geht nur bei Darcs, nicht bei HG/GIT?

> > Was ist in Deinem Beispiel, wenn ich ein paar der Änderungen aus
> > projekt-meinbranch mergen möchte? Geht ja sicherlich genauso, wie anders
> > rum (von modul1-meinbranch -> projekt-meinbranch mergen), aber wie sag
> > ich das?
> 
> Entweder ein "pull" von Modul1 ausgehend, oder ein "push" vom Projekt
> ausgehend. Ist beides äquivalent.
> 
> Problem: Danach wird dein Modul1 *alles* vom Projekt haben. Auch nicht
> gut.
> 
> Darcs hingegen kann das, wiegesagt. Da kannst du einzelne Changesets
> pushen und pullen. Ist für diese Art der Arbeit wohl besser.

Versteh ich nicht. Das Changeset basierte HG kann keine einzelenen
Changesets pushen? Wozu brauch ich dann ein Changeset basiertes SCM?

> > > Hat natürlich den "Nachteil", dass man sein Repository nicht
> > > verzeichnisweise "auseinanderreißen" kann. Vielleicht kann GIT das,
> > > aber Mercurial AFAIK nicht. 
> > 
> > Wieso nicht? Mindestens pull und rm -rf müsste doch gehen, oder?
> 
> "hg rm -r", ja. Aber wenn du diese Änderungen wieder irgendwoanders
> hinschickst, werden die Verzeichnisse dort auch entfernt. Für einmalige
> Aktionen geht es, aber auf Dauer ein Unterverzeichnis wie ein eigen-
> ständiges Repository behandeln, das geht nicht ohne weiteres. Im
> Gegensatz zu CVS und SVN.
> 
> Hab's in Mercurial aber auch noch nie vermisst. Und ja, "irgendwie"
> kriegt man's nur geschickte "hg rm"- und "hg pull"-Aktionen hin,
> genauso wie Subversion "irgendwie" auch Tags und Branches hat. :-)

Für mich sind diverse "doc" und ähnliches gern Kandidaten für sowas,
oder wenn ich neben gemeinsamen Verzeichnissen je eins für Plattformen
haben möchte oder so. Könnte man aber vermutlich auch alles anders
abbilden, wenn man denn müsste. Aber ich sehe das nicht so sehr als
Feature (ob nur ein .hg, naja, eigentlich egal, oder?) als mehr als
Beschränkung. Na ja, "Die Summe der Nachteile ist konstant", was?

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.





Mehr Informationen über die Mailingliste linux-l