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

[Volker Grabsch]

On Wed, Jan 24, 2007 at 10:07:08PM +0100, Steffen Dettmer wrote:
> * Volker Grabsch wrote on Tue, Jan 23, 2007 at 16:23 +0100:
> > Du werkelst weiter. Okay, fertig. Dein branch-A geht in den Trunk:
> > 
> >     $ 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 "hg pull" wird abbrechen, weil gar kein "../branch-A" existiert.
Falls doch, wäre es noch im aktuellen Repository, hat also auch keinen
Effekt. Du meinst vielleicht:

      $ cd ../trunk/directory1/
      $ hg pull -u  ../../branch-A
      $ hg merge

Das hat exakt den selben Effekt wie der erste Befehl.
Warum auch nicht? Die Changesets sind nicht gegen bestimmte
Verzeichnisse "geerdet". Außerdem habe ich längst erklärt, dass
/trunk/directory1/ nichtmal ein ".hg"-Unterverzeichnis hat (nur trunk/
hat eines).

Derartige Gefahren, wie sie in CVS oder Subversion existieren, sind
hier also prinzipiell gar nicht möglich! Wenn man nicht gerade
Subversions "Branches" und "Tags" braucht, ist es auch gar nicht
sinnvoll, dass man jedes mikrige Unterverzeichnis wie ein eigenständiges
Repository behandeln kann.

(wobei ich betonen will, dass man die normalerweise nicht "trunk" oder
"branch-A" nennt, sondern eher sowas wie "feature-A", "feature-B")

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

> > > Nein, man lässt dass einen Kollegen machen. Muss nicht (SOLL nicht)
> > > jeder alles 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!  ;-)

> > > Ich würde bei "hg" erwarten, dass es eine Usage ausgibt. Brauchste gar
> > > kein TAB :)
> > 
> > Ja klar, aber was macht denn die Autovervollständigung? Die gängigen
> > Konfigurationen verarbeiten das Tab bei "hg", "svn" & Co. gerade
> > dadurch, dass sie das Teil mit "--help" aufrufen und dir die Ausgabe
> > präsentieren. Ist sehr angenehm sowas. Spart einem das Eingeben eines
> > extra Befehls für die Hilfsausgabe.
> 
> 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)

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

(Eine analoge Überlegung führt zu der Schlussfolgerung, dass Quellcode
und zugehörige Doku möglichst nah beieinander sein sollten, damit man
nicht bei den Änderungen zwischen Dateien hin und her springen muss)

> > Gibt es hingegen in modul1 eine projektspezifische Änderung,
> > wird sie im Projekt-Repository erledigt, und das Modul1-Repository
> > wird davon niemals etwas mitbekommen:
> > 
> >     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.

Mir ging es doch gerade darum, die "echten" Modul-Änderungen sauber
von den Änderungen zu trennen, die nur ein einziges Projekt betreffen,
und auch dort früher oder später wieder rausfliegen (sobald das Modul
eine saubere Lösung dafür hat).

> 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 :-)

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.

> > Schick, oder? Deine Hacks bleiben in einem Repository, in einem
> > Branch, zusammenhängen in einem commit (changeset). Die richtigen
> > Modul-Änderungen hingegen passieren in den Modul-Repositories.
> 
> 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.

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

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

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.

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

> > Der einzige Trick hierbei ist, dass man "hg pull" nur in ein
> > Richtung anwendet (vom Modul zum Projekt) und niemals andersrum!
> 
> huch. Ja?
> 
> 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.

> Ich mein, irgendwie muss ich ja die Änderugen identifizieren.
> Also in CVS würde ich zwei Tags haben. Wie mach ich das hier?

Geht auch, wiegesagt. Dann würde mein Szenario anders aussehen:
Projekt/Modul1 wäre ein eigenes hg-Repository, und du mergst zwischen
*dem* und deinem zentralen Modul1-Repository.

Vorteil: Du kannst Änderungen dort auch zum zentralen Modul1-Repository
zurückbringen. (ganz genauso wie bei deiner CVS-Variante, nur dass
du im zentralen Repo keinen Branch anlegen brauchst)

Nachteil: Projektspezifische Änderungen ("Hacks") landen genauso dort.
Und das wollte ich mit meinem Alternativ-Weg ja verhindern.

Meine Alternative ist wohl doch nicht so praktikabel. :-(

> > Du willst dein Projekt vom einen Modul-Branch zu einem anderen
> > migrieren (neuere Lib-Version)? Kein Problem. Das ist nur ein
> > "hg pull" mit anderer Quelle:
> > 
> >     hg pull -u  ../modul1-version2/
> 
> Das mergt mir dann die Changes von -version1 zu -version2 rein, ja?

Ja.

> > Ach ja, man kann natürlich Default-Werte für "hg pull" und "hg push"
> > setzen, versteht sich. Für das Prokekt-Repository nicht so
> > interessant, wohl aber für den Kunden. :-)
> 
> erm... Default-Werte?! Versteh ich nicht. Sowas wie Quellbranch
> einstellen ist damit gemeint?

Ja, sozusagen. Dem "hg pull" musst du doch sagen, *woher* es die
Änderungen holen soll. Das ist ein Parameter. Wird er nicht angegeben,
braucht er einen Default-Wert.

Bei einem "hg clone" (sowas ähnliches wie cvs checkout) wird dieser
Default-Wert schon automatisch gesetzt ... auf die Quelle des "hg clone".

> > Was hältst du von dem Weg, den ich demonstriert habe? Ist doch auch
> > recht fix und elegant, oder? Und es ist auch dann sicher, wenn man
> > keine atomischen Repo-übergreifenden Commits hat. :-)
> 
> Na, der Unterschied, den ich sehe und evtl. verstehe, ist, dass der Satz
> hier komisch ist. Nee. Nochmal.
> 
> Der Unterschied scheint, dass ich in projekt-meinbranch einchecken kann,
> aber automatisch Änderungen aus dem Modul kriege. Nee, nicht
> automatisch, ich mach pull. Kriege also nur das, was ich will. ok.

Ja.

> > > Aber was ich wie und wohin auschecke, ist
> > > doch nur meine lokale Sicht?
> > 
> > Es gibt kein "auschecken". Man Clont/Kopiert ein anderes Repository.
> > (siehe Beispiele oben)
> 
> mmm, klingt cool. Wo werden die Änderungen dann eigentlich technisch
> gespeichert?

In einem Unterverzeichnis namens ".hg" im Repository/Workdir.

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


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR