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

Steffen Dettmer steffen at dett.de
Mi Jan 24 22:07:08 CET 2007


* 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

Ich rate mal es geht und es kommt ganz herrlich gequilrte Sch____ bei
raus ;)

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

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

> (genauso wie einem die klassische Tab-Vervollständigung einen extra
> "ls" erspart ... man kann stattdessen direkt seinen längeren Befehl
> weiter tippen)

Nee, das benutzt man gern, wenn schon ein halbes Kommando dasteht. Na,
details.

> > Wir waren ja bei "atomar": ist "hg up *" atomar? 
> 
> Nein. Davon abgesehen: Einen *wirklich* atomaren Commit über mehrere
> Repositories hinweg, die im Netzwerk auf verschiedenen Rechnern liegen,
> stelle ich mir auch technisch unmöglich vor. 

> Ich meine, das Protokoll müsste doch so aussehen:

ich änder das mal
 
> Client -> Server1   BEGIN
> Client -> Server1   commit, Daten
> Client -> Server2   BEGIN
> Client -> Server2   commit, Daten
> Client -> Server3   BEGIN
> Client -> Server3   commit, Daten
> Client -> Server4   BEGIN
> Client -> Server4   commit, Daten
> 
> ... 5min später ...
> 
> Server3 -> Client   ok, warte auf Bestätigung
> Server2 -> Client   ok, warte auf Bestätigung
> Server4 -> Client   ok, warte auf Bestätigung
> Server1 -> Client   ok, warte auf Bestätigung
> 
> Client -> Server1   bestätigt
> Client -> Server2   bestätigt
> 
> ... Netz bricht ab ...
> 
> Client -> Server3   bestätigt  [kommt nicht an]
> Client -> Server4   bestätigt  [kommt nicht an]

--> Kein COMMIT (der "commit, Daten" transaktion), atomar "nichts"
gemacht (das ist ja ok).

Client -> Server3      ROLLBACK
Client -> Server4      ROLLBACK

(1 und 2 unerreichbar, muss man später)

Das geht logisch natürlich nur so "zirka". Man kann das
Problemzeitfenster auf die Dauer von 4 COMMITS reduzieren. Was ein Repo
mit offener Transaktion sein soll, ist auch nicht so ganz klar.

Kurz: der Kram skaliert (so oder so) nicht :)

> > Aber wie gesagt, ist IMHO nicht sooooo wichtig.
> 
> ACK.
> 
> > > > > Ich wüsste nicht, wieso ich in solch einem Szenario
> > > > > modulübergreifend mergen wollte.
> > > > 
> > > > Na, Du hast einen release branch, machst einen Fix (der Änderungen in
> > > > drei Repos braucht) und willst das halt in den trunk mergen.
> > > 
> > > Will man das wirklich? Alles auf einmal?
> > 
> > Ja, natürlich, wie sonst?!
> [...]
> 
> Okay, ich verstehe deine Ausführungen. Danke für die Erläuterungen.
> 
> Es gibt also Änderungen, die man in das Modul zurückfließen lassen
> möchte, daher braucht das Modul sein eigenes Repo.
> 
> Es gibt andererseits auch Änderungen, die nicht zurückfließen
> sollen und eng mit dem Hauptprojekt verwoben sind (Hacks). Das
> späche dafür, beides (für das Release) in ein einziges Repository
> zu packen.
> 
> Das Modul kann also innerhalb des Projektes sowohl Modul-spezifische
> als auch Projekt-spezifische Änderungen haben. Die Projekt-spezfischen
> müssen aber leider auch in das Modul eingecheckt werden. Dieser
> Missstand wird durch ein atomares Commit in beide Repositories
> erträglich gemacht.
> 
> Bei CVS und Subversion wüsste ich auch nicht, was man da machen
> kann. Mit Mercurial & Co. hingegen würde ich das relativ elegant
> lösen können:
> 
> Module haben eigene Repositories mit jeweis genau einem
> Unterverzeichnis:
> 
>     modul1-meinbranch/
>         modul1/
>             [Modul1-code]
> 
> Das Projekt hat ein anderes Repository das erstmal nur Projekt-Code hat:
> 
>     projekt-meinbranch/
>         [Projekt-Code]
> 
> Die benötigten Module werden via "hg pull" reingeholt:
> 
>     cd projekt-meinbranch/
>     hg pull -u  ../modul1-meinbranch/
>     hg pull -u  ../modul2-meinbranch/
>     hg pull -u  ../modul3-meinbranch/
> 
> Das Aktualisieren funktioniert auf exakt dem selben Wege.
> Das Projektverzeichnis sieht dann so aus:
> 
>     projekt-meinbranch/
> 
>         [Projekt-Code]
> 
>         modul1/
>             [Modul1-code]
> 
>         modul2/
>             [Modul2-code]
> 
>         modul3/
>             [Modul3-code]
> 
> Gibt es eine Änderung in modul1, die alle Projekte betrifft,
> wird sie im Modul1-Repository erledigt:
> 
>     modul1-meinbranch/
>         modul1/
>             [neuer Modul1-code]
> 
> und via "hg pull" wie gehabt in das Projekt geholt:
> 
>     projekt-meinbranch/
>         [Projekt-Code]
>         modul1/
>             [neuer Modul1-code]
>         modul2/
>             [Modul2-code]
>         modul3/
>             [Modul3-code]
> 
> 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? Kann
man da nicht "genauso nur andersrum" pullen?

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

Also, ich soll die Sourcen nicht im projekt-Verzeichnis ändern? Sondern
in einem modul1-meinbranch? Wie teste ich das denn vor'm einchecken?

In CVS würde ich es einfach in projekt-meinbranch einchecken. Das
Problem kriegt man natürlich nachher beim mergen.

> 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? Ich mein, irgendwie muss ich ja die Änderugen identifizieren.
Also in CVS würde ich zwei Tags haben. Wie mach ich das hier?

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

> Natürlich musst du jetzt sämtlich Konflikte zugunsten von version2
> lösen, aber das kann auch positiv sein, wenn du z.B. deine Hacks
> am alten modul1-meinbranch behalten willst. Einfaches Rüberbügeln
> geht jedenfalls ohne  großen Aufwand.

Das ist klar :)

> Ist natürlich nur eine Möglichkeit von vielen, ich wollte nur mal die
> Power von Mercurial & Co. demonstrieren.

Na, das oben ist aber nur ein Vorteil, weil ich kein zentrales Repo mit
Schreibrechten brauche, oder? Geht doch mit CVS genauso? Vielleicht sind
die Kommandos anders (und mehr wegen taggen). 

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

> > In der Praxis muss man evtl. auch mal was dreckiges in so einem Branch
> > machen. Stört nicht weiter, wenn im trunk des modul1 das schon durch
> > andere Massnahmen (Refakturierung oder so) gelöst ist (sprich: in -Fixes
> > branches kann man notfalls hacken, wenn's nie gemergt werden wird,
> > macht's kaum was). Gut, mein Beispiel war natürlich gerade ein anderes,
> > merk ich gerade :)
> > 
> > Jedenfalls geht schön, schnell und elegant mit CVS finde ich.
> 
> 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.

Also wie in CVS, nur sind ggf. die Kommandos einfacher; das sieht
man hier ja nicht.

Die Stärken müssten ja erst dann zu sehen sein, wenn man Abhängigkeiten
von Changes hat etc pp - oder?

> Ich finde einen Webserver mit CGI-Script leichter abzudichten als einen
> SSH-Zugang. Bei ersterem kannst du "per se" erstmal nur so viel, wie
> dein CGI-Script an Sicherheitslücken zu bieten hat. Bei SSH hingegen
> kannst du erstmal alles.

CGIs darf per default jeder, SSH per default keiner...

Na egal, könnte man ewig rumlabern, klar.

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

> > Geht das mit HG nicht? hum, dass wäre ja
> > eine Einschränkungen...
> 
> Finde ich nicht. *Innerhalb* eines Repositories kannst du natürlich
> zu jeder beliebigen älteren Version "springen"  (hg update -r ...).
> 
> Mit dem .hg-Verzeichnis hat das aber erstmal nichts zu tun. Ich meinte
> nur, es gibt nur ein solches Verzeichnis, in dem *alles* drin steckt,
> statt die Versionsinfos sinnlos auf Unterverzeichnisse aufzuspalten.

Find ich nicht schlecht, so kann ich mir eine Struktur beliebig
zusammenbasteln. Also, angenommen:

moduleM1
moduleM1/m1d1
moduleM1/m1d2
moduleM1/doc

moduleM2
moduleM2/m2d1
moduleM2/m2d2
moduleM2/doc

Dann kann ich mir ja auschecken:

moduleM1
moduleM1/m1d1
moduleM1/m1d2
moduleM1/m2d2   <-- M1 !!
moduleM1/doc    <-- sei das aus M2!!
moduleM1/m1doc  <-- aus m1

Das geht doch nur, wenn ich überall Verzeichnisse hab. Andererseits
braucht man das bei HG nicht, weil man eh alles einzeln
zusammenpollenpushen muss, was andere haben sollen. Nee, Moment, geht in
HG genauso, nur das "technisch" das Kopien wären. Wie ja in Deinem
Beispiel oben, verschiedene Repos oder wie das korrekt heisst. Stimmt,
geht wieder in beiden Fällen.

Na, ist eigentlich auch klar, dass am Ende mehr oder weniger das gleiche
bei rauskommt. Das heisst ja nur, dass man mit beidem arbeiten kann.

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

> Sehe ich aber nicht als wesentliche Einschränkung an. 

auseinanderreißen könnte man missen, aber zusammenbasteln muss gehen,
aber das geht ja.

oki,

Steffen

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





Mehr Informationen über die Mailingliste linux-l