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

[Volker Grabsch]

On Sat, Jan 27, 2007 at 02:59:29PM +0100, Steffen Dettmer wrote:
> * 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.

Hab ich nicht gerade erklärt, *dass* dem nicht so ist, und
*warum* den nicht so ist?

Akzeptier doch einfach, dass Mecurial, Darcs, GIT in diesem
Punkt es einfach mal "richtig" machen, so wie man's erwartet.
Für genauere Erklärungen lies meine letzte Mail einfach nochmal.

Wenn du's immer noch nicht glaubst, dann probier es halt aus.

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

Doch, Mercurial weiß es, denn es gibt nur *ein* .hg-Verzeichnis.
Es kennt die Wurzel deines Checkouts und orientiert sich nur daran.
Genaueres siehe letzte Mail.

Vielleicht noch eine Ergänzung. Lokale Befehle wie
    hg commit
    hg diff
    ...
machen ihre Aktion jeweils im gesamten Repository, selbst wenn du
den Befehl von einem Unterverzeichnis aus startest. Trotzdem kannst
du natürlich nur bestimmte Dateien & Verzeichnisse beachten lassen.
Willst du z.B. nur das aktuelle Verzeichnis (inkl. Unterverz.) diffen,
machst du:
    hg diff .

So einfach ist das. IMHO verhält sich Mercurial genau richtig. Man muss
nicht sicherheitshalber immer zur Wurzel zurückkehren, nur um sicher
zu gehen, wirklich *alle* Änderungen zu haben. Ist mir in CVS & SVN
schon so oft passiert, dass ich Änderungen in einem übergeordneten
Makefile oder in der README im Commit vergaß, bloß weil ich gerade
im "src/" Unterverzeichnis war.

Nein, dann doch lieber andersrum: Der Commit bezieht sich auf alles,
und beim Eintippen der Message sehe ich ja, was er alles committen
will. Merke ich, dass ich eigentlich nur bestimmte Sachen drin haben
will, und den Rest separat committen will, dann breche ich ab und gebe
dem "hg commit" noch einen Parameter.

Ist viel weniger fehleranfällig und IMHO meistens das, was man
eigentlich erwartet (wenn man nicht CVS/SVN-vorgeschädigt ist, so
wie wir ;-)).

> 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

Das mag sein. In dem Fall solltest du nicht nach SVN wechseln. Leicht
abweichende Anforderungen könnten aber dazu führen, dass für ein
Projekt SVN wieder besser ist.

> (SVN ist IMHO sehr ähnlich zu CVS; HG und Co sind dagegen eine
> Dimension höher).

Diese Schlussfolgerung würde ich nicht gleich ziehen. Auch SVN hat
bemerkenswerte Fortschritte gegenüber CVS. Aber es sind auch ein
paar Sachen auf der Strecke geblieben, wie du selbst bemerkt hast.

In deinem konkreten Projekt wiegen die in SVN fehlenden Features
die neuen gegenüber CVS vielleicht nicht auf. Aber daraus kannst
du nicht schließen, dass die Verbesserungen in SVN für jedermann
uninteressant sind. Oder noch schlimmer, dass die HTTP-Sache das
interessanteste sei. (im Gegenteil, ist nur ein interessanter
Nebeneffekt)

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

Du hast mich immer noch falsch verstanden: Mercurial hat *keine*
eingebaute Tab-Autovervollständigung. Natürlich läuft das, wenn
überhaupt, durch eine entsprechende Shell-Konfiguration, die --help
aufruft.

Ich habe lediglich erklärt, warum sie sinnvoll ist. Hat nichts
mit Mercurial vs. SVN oder ähnlichem zu tun.

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

Das ist in Mercurial nicht vorgesehen und aus den bereits geschilderten
Grünen m.E.n. nicht nötig.

Es geht doch gerade darum, dass du eben *nicht* anfängst, selbst über
jede Änderung Buch zu führen. Wenn du verzeichnisweise mergst, tust
du genau das händisch, was Mercurial & Co wegautomatisieren.

Bevor du jetzt mit "CVS ist besser als SVN *und* als Mercurial"
ankommst:   :-)

Du kannst nicht erwarten, dass alte Verhaltensmuster aus CVS auf
verteilte VK eins zu eins anwendbar sind. Willst du bisherige
Gewohnheiten beibehalten und nur andere Kommandos verwenden, wirst
du von *keiner* Versionskontrolle außer CVS profitieren. Und dasselbe
würde gelten, wenn du mit Subversion angefangen hättest.

Wie das bei GIT mit verzeichnisweisem Merging aussieht, weiß ich nicht.
Ich glaube aber nicht, dass das Kernel-Projekt damit unglücklich ist.
CVS kam für sie niemals in Frage, es ist damals wie heute zu primitiv
für den Job. Und ich glaube bei allem Respekt vor eurer Firma nicht,
dass ihr höhere Ansprüche an eine VK habt als das Kernel-Entwickler-
Team. Gib modernen Methoden eine Chance, statt zu versuchen, alte
Methoden mit moderneren Werkzeugen zu beschreiten.

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

Die Verwaltungsmöglichkeiten der verteilten VK sorgen gerade dafür,
dass genau das *kein* Problem darstellt.

> Der Maintainer möchte das ja dann einfach mergen können, oder?

Richtig. "Einfach Mergen". Nicht bestimmte einzelne, niemals
alleinstehend getestete, Änderungen herausfitzeln und woander einfügen.
Wenn du diese Lowlevel-Arbeit unbedingt machen willst, solltest du bei
CVS bleiben. Man kann auch 100kB große Programme in reinem Assembler
schreiben.

Willst du hingegen nur noch auf höherem Level arbeiten, also *wirklich*
"einfach nur mergen", dann verlange, dass jedes kleinere Feature einen
*extra* Branch kriegt, also in einem extra Repository unabhängig vom
Rest entwickelt und getestet wird. Andere stabile Features kann es
von überall reinholen, und auch dort sicherstellen, dass die Integration
klappt. Jederzeit können von irgendwoher andere Features mit reinkommen.
Oder auch nicht, ganz wie man's machen will.

Auf dem Level arbeitet es sich gut. Nennt man "Microbranches", wiegesagt.
Klingt nach Resourcenverschwendung, aber gerade die verteilten VK sind
auf Performance getrimmt (naja, Darcs nicht). Außerdem ist Entwicklungs-
Zeit teurer als Speicherplatz und Rechnerleistung, aber das brauch ich
dir ja nicht erklären. :-)

Viele Commits in ein und dasselbe Repository (bzw. in ein und den selben
Branch), und dann noch bestimmte daraus herauskramen. Nee, da ist schon
der Ansatz falsch.

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

Zu GIT kann ich da nichts sagen.

Aber in HG: Ja, da ist das nicht vorgesehen. Wiegesagt, jeder Merge ist
ein extra Commit. Das beißt sich nunmal höllisch mit "Changesets kann man
weitestensgehend unabhängig voneinander herumschieben". Das ist genau
das Thema!

Einerseits stimmst du mir zu, dass dieses "Merging ist ein extra Commit"
von HG etwas sehr Gutes und Sinnvolles ist. Andererseits willst du wie
in Darcs die Changesets wild herumschieben und damit viele potentiell
ungetestete Kombinationen ermöglichen.

Entscheide dich, das ist eine konzeptuelle Frage. Ich finde das Konzept
vom Mercurial sinnvoller, habe aber anfangs auch mit Darcs intensiv
gearbeitet, und deren Vorgehensweise hat auch was für sich.

> Wozu hätte ich denn dezentrale Repositories, wenn ich die (einige der)
> Änderungen nicht zurück in das Repository schieben kann, wo es herkam?

Du kannst es in HG. Aber nur ganz oder gar nicht.

Willst du's auftrennen, mach mehrere Branches (Repositories) dafür auf.
Ist nur ein "cp -a" bzw. "hg clone" weit entfernt.

> Oder auch von dem Repository aus "reinziehen" kann (was das gleiche sein
> sollte, oder?).

"hg push" und "hg pull" sind symmetrische Operationen. Genau wie "darcs
push" und darcs pull". Ja, es geht nur darum, von welchem Repository
die Initiative ausgeht. (... und wie man die Zugriffsrechte regelt)

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

Zentrale Verwaltung ist nur ein Spezialfall der dezentralen. Natürlich
ist es sinnvoll, ein oder zwei "Haupt-Repositories" festzulegen, in die
früher oder später alles reinkommt. Das hat aber nur was damit zu tun,
dass es einen "trunk/" geben sollte. Mit "zentrale vs. verteilte VK"
hat das nichts zu tun.

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

Ja, hier sind wir bei Darcs-Changesets versus Mercurial-Changesets
angelangt. Beide sind weitausmächtiger als das, was Subversion unter
Changesets versteht. Aber das Konzept von Darcs ist etwas flexibler
als das von Mercurial. Dafür kann Mercurial die "echten" Merges von
den "potentiellen" Merges unterschieden.

[Unterverzeichnisse sind keine eigenständigen Repositories]
> 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?

Ich finde, die "Beschränkung" ist keine, da du bei Bedarf jederzeit
ein neues Repository in einem Unterverzeichnis anlegen kannst.

Der Weg der verteilten VK hat insgesamt viel weniger Nachteile finde
ich. Das meiste, was zunächst wie ein Nachteil oder eine Einschränkung
aussieht, ist in Wahrheit ein Indiz dafür, dass man es sich früher zu
kompliziert gemacht hat. So zumindest meine Erfahrung. YMMV. Probier's
einfach mal aus.


Viele Grüße,

    Volker

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