[linux-l] Re: VCS

Sa Apr 22 23:11:51 CEST 2006

On Thu, Apr 20, 2006 at 11:48:50PM +0200, Steffen Dettmer wrote:
> Das Beispiel ist wie folgt: Du schickst mir ein File zur Info einfach
> aus Deiner Sandbox. Sagen wir mal "hallo.c". Du arbeitest weiter. Drei
> Wochen später schicke ich Dir hallo.c zurück und bitte Dich "das file
> bitte einzuchecken". Nun geht das nicht, weil Du es auch geändert hast.
> Jetzt hättest Du gern ein unified diff, geht aber auch nicht, weil Du
> das Orginal der Datei nicht hast.
> 
> Hilft Dir SVN hier?

Ja und nein. Einerseits steht's nicht in der Textdatei drin.
Andererseits kannst du demjenigen die aktuelle (globale) SVN-Nummer
mitteilen (oder im Dateinamen codieren, hallo-r1232.c), dann kannst
du damit weiter verfahren wie bei CVS.

> Bei CVS und Keywords ist das einfach: in $Name$ oder $Header$ steht, was
> das genaue Orginal war. Also kann man in dem Fall diese Version holen
> (up -r <name>), dann das File drüberkopieren. Die Änderungen sieht man
> dann via cvs diff, kann das diff zum Branchpoint hochziehen (falls keine
> Konflikte) oder als Branch einchecken und zum Branchpoint mergen, wie
> auch immer.

So sieht das in Subversion auch aus.

Und, wiegesagt, es funktioniert auch bei mehreren Dateien, d.h.
wenn du ihm ein ganzes Verzeichnis (als TarGZ, ZIP, ...) schickst,
brauchst du nur eine Versionsnummer nehmen, und nicht jede Datei
einzeln mit Versionsnummer auschecken und reinfrimeln.

Wie das in Changeset-basierten SCM aussieht, weiß ich leider nicht.
Wiegesagt ist dort das allgemeine Vorgehen eher so, dass du jemanden
eine oder mehrere Dateien gibst, und *er* dir gleich einen unified diff
(aka "patch") zurückgibt. Bei freier Software ist das gang und gäbe.

> > Ich verstehe daher nicht dein Problem.
> Es geht um Fälle, wo der Bearbeiter kein SVN hat/will/nimmt.

Das geht.

Bei Darcs, GIT, Mercurial, ... weiß ich es aber nicht so genau.
Ich persönlich würde mir wahrscheinlich einfach ein Tag setzen.

Ich war übrigens vor kurzem auch in diese Lage, aber ich habe
die alte Mail noch gehabt, und direkt den Diff gemacht. :-)

Schöner wäre es natürlich, wenn der Gegenüber einen Patch produziert,
aber davon kann man nicht immer ausgehen.

> > Außerdem dachte ich, solche Probleme gehören zu ISO-9000, nicht 9001,
> > aber ich kenn mich da nicht wirklich aus. ;-)
> 
> Laut Wikipedia:
[...]

Cool, Wikipedia beschreibt diese Standards? Wusste ich gar nicht.

> > Der Unterschied ist, dass dann das Repository "sauber" bleibt, statt in
> > ein Chaos von verschiedenartigen Zeilenenden zu verfallen.
> 
> Im Repository sind bei uns immer Unix-LFs, egal, wie ein Client die nu
> auscheckt. Oder was meinst Du?

Ja, das meinte ich.

> > > Ich nehme ein File und verschicke es per eMail. Ich bekomme es geändert
> > > zurück. Nun möchte ich es einchecken.
> > 
> > Das ist IMHO ein sehr schlechtes, CVS-zugeschnittenes Beispiel. Erstmal
> > wird es keine einzelne Datei sein, sondern wahrscheinlich mehrere,
> > vielleicht ein ganzes Verzeichnis.
> > 
> > Außerdem ist es AFAIK eher üblich, dass man die Datei(en) gar nicht
> > explizit verschickt, und auf keine Datei zurückbekommt, sondern einen
> > Patch.
> 
> Wunschdenken! In der OpenSource-Gemeinschaft mag die Genialität von
> "patch" ja schon lange angekommen sein, aber in der Praxis seh ich oft
> Leute mit bunten diff-Tools oder Word-Dokumente-Vergleichen - FALLS man
> denn schon ein Tool verwendet...

Ja, wirklich schade. Ich bastel momentan für jemanden eine Homepage,
und lass ihn die Inhalte (in eine Plaintext-Datei) selbst bearbeiten.
Von ihm kann ich auch keine Patches erwarten, andererseits trennen wir
die Arbeit relativ gut. Außerdem, wiegesagt, hab ich ja jeweils noch
die alten Mails.

Von einem Programmierer jedoch erwarte ich eigentlich, dass er sich
die 5min mal nimmt, um "diff" bedienen zu lernen!

    diff -u DATEI.orig DATEI > mein-patch

    Billiger geht's doch gar nicht mehr!

Neuerdings habe ich übrigens sogar für jedes Projekt (im abstrakten Sinne)
einen eigenen Mailordner, so ist mein komplettes Mail-Archiv aufgebaut.
Natürlich mach ich mir immer Kurznotizen (TODO-Listen), und hab nen
Terminkalender.

Aber *wenn* mal was ist, dann finde ich in Nullkommanix die
entsprechende EMail wieder. Sehr praktisch, sowas. :-)

> Das Beispiel funktioniert mit mehreren Dateien genauso, und zwar machen
> wir sowas manchmal mit "source distributionen", also "cvs export -r
> fuer_den_und_den && make dist | mail" sozusagen.
> 
> Aber schon klar, das Beispiel hinkt hier und da ;)

Jo, wiegesagt kannst du ja auch für jeden ein Tag anlegen. Klappt
in CVS, Subversion, Darcs, ...

Das wäre für solche Fälle IMHO die kanonische Vorgehensweise.

> > Ich stelle diese Szene mal in Subversion dar:
> > 
> > Du versendest mehrere Dateien aus einer bestimmten Version. Im Namen
> > des TarGZ bzw. in der Mail nennst du die Revision. Ist nur eine Zahl,
> > etwa 1054.
> > 
> > Dann bekommst du ein TarGZ oder einen Patch zurück. Patch wäre natürlich
> > cooler. Ist dein Gegenüber nicht zu einem unified-patch in der Lage,
> > dann eben das ganze geänderte TarGZ. Ist er auch zu blöd, dir die Revision-
> > Nummer zu nennen, hast du immer noch den Absender der Mail. Ist er auch
> > dazu nicht in der Lage, dann packst du eben eine Datei namens "REVISION"
> > vorher ins TarGZ. Wenn er auch die ändert ... na gut, dann würde er bei
> > CVS auch $Header$ ändern, d.h. im Worst-Case an Dummheit funktioniert
> > auch CVS nicht.
> 
> Ja, OK, man kann es abbilden. Aber ich seh nicht den Vorteil von so
> einer Datei gegenüber $Header$ / $Name$.

Ich sehe den Vorteil darin, dass in der Datei wirklich nur der Quellcode
drinsteht, und dass Meta-Infos im Dateinamen, Archivnamen oder im Archiv
selbst stecken. Also einfach eine bessere Trennung.

Ob man diese Trennung will oder nicht, ist natürlich Geschmackssache.

> > In Darcs & Co. hast du zwar keine zentralen nummern, aber ebenfalls
> > Tags. Zu legst also ein Tag ein, sobald du die Datei(en) verschickst.
> > (z.B. "ronald-2005-10-04", oder wie auch immer du das organisieren
> > möchtest)
> 
> Also genau wie bei CVS, nur dass man das Tag nicht in den Sourcen
> vermerken kann.

Sozusagen. Aber wiegesagt finde ich diese Trennung ganz sinnvoll.

> Einige Software macht sowas was cooles: es wird geprüft, ob "$Name: $
> hinter dem Doppelpunkt einen Bezeichner hat oder nicht. Hat es keinen,
> nennt sich die Software "experimental, not to be released" oder sowas
> :-) Das "zwingt" dazu, nur reproduzierbare Versionen zu erzeugen.

Was noch schöner wäre, wär wenn CVS das automatisch macht, d.h. bei
anwesenden $Header: ...$ diese Datei von vornherein nur gegen das
"richtige" Original vergleicht.

Man könnte sich diese Datei(en) in sein Verzeichnis packen, macht
"cvs di", und sieht nur die eigentlichen Änderungen. Vielleicht
noch ein Vermerk, dass die Datei nicht aktuell ist. (bei Subversion
könnte man das in "svn status" einbauen)

Ein "commit" darf man noch nicht machen, wohl aber ein "update", das
die Datei dann auf den neusten Stand bringt. Sowas wäre bestimmt cool.
Und dafür könnte man diese $Header: ...$ dann IMHO gut gebrauchen, aber
eine Kodierung im Dateinamen würde es genauso tun.

Aber im status quo, wo sowieso nen Haufen Handarbeit dabei ist, sehe
ich keinen wirklichen Vorteil, ob die Versions-Info nun im Datei-Inhalt
oder im Datei-Namen steckt.

Hast du einen Ideoten am anderen Ende der Leitung, hilft sowieso alles
nichts, da *musst* du dir dann notieren, welche Version zu ihm zuletzt
geschickt hast (bzw. die Mail aufheben). Immerhin kann es genauso
passieren, dass er die Datei umbenennt, wie dass er den $Header: ...$
ändert.

> > > Möglicherweise liegt hier ein Missverständnis vor. Das SCM darf die
> > > Reproduzierbarkeit nicht verletzen. Also keinen $State$, der sich später
> > > ändern kann oder so. Aber das macht ein $Name$ nicht. Checke ich es
> > > zweimal aus, bekomme ich zweimal exakt das gleiche. Es ist
> > > reproduzierbar. Hier ist nämlich nicht gefordert, dass dieses Ergebnis
> > > jemals so eingecheckt wurde, nur, dass man einen "export" immer wieder
> > > später genau wiederholen kann.
> > 
> > Genau das bieten dir Tags im Allgemeinen, und die werden von jedem VCS
> > unterstützt.
> 
> Ja, aber auch mit Keyword-Expansion bleibt das Reproduzierbar.

Ja, eben. Eine Kodierung im Dateinamen wäre damit genauso ISO-9001
zertifizierbar, oder?

> > > Ich höre immer: es ist besser und dies und das. Aber was helfen mir denn
> > > die ganzen Features wirklich? Ich kann mir das kaum was vorstellen. Oder
> > > HTTPS+SOAP+XML+WEBDAV. Was bitte hab ich davon, ausser das es langsam
> > > ist, das XML Overheadlastig und in fast allen Anwendungen falsch ist
> > > (ASN.1 müsste man nehmen, viel älter und viel besser)
> > 
> > Kannst du das genauer erläutern?
> 
> Was denn? Warum HTTPS+SOAP+XML+WEBDAV nicht wirklich was bringt? Oder
> warum HTTPS+SOAP+XML+WEBDAV langsamer ist als die gleichen Daten nicht
> in 1000 byte Text sondern in 20 Byte binär-TLV (via ASN.1) zu kodieren?

Nein, meine Frage war eigentlich, was ASN.1 ist, aber wenn das ein
bereits lange gültiger Standard ist, informiere ich mich selbst. Hab
davon schon öfters gehört.

> Oder warum mir ASN.1 besser gefällt?

Ja, das ist auch eine gute Frage. Ich meine, ist ASN.1 wenigstens
textbasiert? Ein Binär-Protokoll finde ich nämlich nicht sonderlich
erstrebenswert. Zahlen sollten übers Netzwerk IMHO als "1235363.23"
kodiert werden, also menschenlesbar.

Für Strukturen gibt's YAML und JSON, aber gegen XML hab ich auch nichts,
wenn man die Vorteile gebrauchen kann. (z.B. für Markup-Text ist es
super, aber nicht unbedingt für die Steuererklärung)

Andererseits kann man XML komprimieren (z.B. HTTP+deflate), das wird
dann etwa genauso klein wie komprimiertes JSON, glaub ich.

Dass jedoch HTTP+XML+WEBDAV+DAV_SVN ziemlicher Overkill ist, hab ich
nie bestritten. ;-)

> Mal ehrlich, gäbe es kein Java, wäre der XML-Hype nur halb so gross und
> Software doppelt so schnell ;)

Mag sein. XML wird vielfältig missbraucht. Ich glaube, in 90% aller
realen Anwendungen reicht auch JSON, ja, es wäre sogar besser geeignet.
(schneller zu parsen, weniger Bandbreite auch ohne Kompression,
menschenlesbar, ...)

> > Ein CGI-Script, das sowohl für Menschen als auch für Tools gut
> > bedienbar ist, ist IMHO das Optimum an Interoperabilität.
> 
> Ja, aber was bringt das? Warum nimmt der Mensch nicht eine
> Java-Swing-GUI und das Tool einen Stream, RPC oder sonstwas?

Weil du dann eine höhere Einstiegshürde hast, die man z.B. bei Wikis
nicht will. Einen Browser hat jeder.

Spezielle Clients hingegen muss man erst installieren. Wie wird
man auf das Programm aufmerksam? Meist übers WWW. Das heißt, jemand,
der es ausprobieren will, hat zumindest schonmal nen Browser.

Steigen seine Ansprüche, ist eine klassische GUI (Java-Swing, .NET,
Python+wxWindows, was-auch-immer, ...) natürlich besser geeignet.

> > Zum Beispiel wurden Mercurial
> > und GIT verglichen (Benchmark-Tests), indem man die Kernel-Quellen genommen
> > hat. Siehe die URLs, die ich bereits hier genannt habe.
> 
> mmm... den Vergleich muss ich übersehen haben.

Hier nochmal mein Absatz:

| Ein Artikel, der Mercurial gegenüber GIT hervorhebt:
|     http://lwn.net/Articles/151624/                 
|
| In den Kommentaren wird jedoch einiges relativiert, etwas weiter
| unten werden auch Vergleich zu anderen bekannten VCS gezogen.
| (Arch, Bazaar, Monotone, darcs, Codeville)
|
| Eure persönliche Meinung GIT vs. Mercurial interessiert mich aber
| weiterhin.

> > Schönes reales Beispiel aus dem "echten Leben". Die Kernel-Quellen sollten
> > jedenfalls deine Ansprüche an Größe und Branches erfüllen.
> 
> Ja, OK, aber ist vermutlich doch recht spezifisch. Weiss nicht, ob man
> die Kernel-Welt so auf meine Firma übertragen kann... Von wegen
> Markt-Und-Kathedrale und so...

Bitte verdreh die Aussage nicht. Es ging an dieser Stelle darum, dass
du gefragt hast, wie man eine neue Versionskontrolle einem realen
Belastungstest unterziehen kann. Und bei GIT ist dies wiegesagt längst
geschehen.

Ob changeset-basierte SCM bei euch in der Firma ihren Nutzen entfalten,
ist eine völlig andere Frage und hat natürlich nichts mit dem Linux-
Kernel-Projekt zu tun, sondern mit *euren* Arbeitsabläufen.

Viele Grüße,

    Volker

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