[linux-l] Re: VCS
Steffen Dettmer
steffen at dett.de
Do Apr 20 23:48:50 CEST 2006
* Volker Grabsch wrote on Sat, Apr 15, 2006 at 14:53 +0200:
> On Fri, Apr 14, 2006 at 11:58:43PM +0200, Steffen Dettmer wrote:
> > Ich interpretiere das so, dass sowas wie $Header$ und $Name$ nicht geht.
> > Damit sehe ich dann den Files nicht an, wie ich sie im SCM
> > identifizieren kann. Und das ist doof. Identifizierbarkeit ist eine
> > Grundforderung eines jeden sauberen Prozesses. Gut, man muss Darcs ja
> > nicht gleich ISO 9001 zertifizieren ;)
>
> Das verstehe ich nicht. Wenn ich die Datei vor mir habe, dann kann dir
> z.B. Darcs ganz genau sagen, welches die letzten Änderungen waren.
>
> Es kann dir also quasi ein Changelog speziell fur diese Datei geben.
> (bzw. Gruppe von Dateien bzw. Verzeichnissen)
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?
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.
> Ich verstehe daher nicht dein Problem.
Es geht um Fälle, wo der Bearbeiter kein SVN hat/will/nimmt.
> Außerdem dachte ich, solche Probleme gehören zu ISO-9000, nicht 9001,
> aber ich kenn mich da nicht wirklich aus. ;-)
Laut Wikipedia:
"EN ISO 9000 [...] definiert Grundlagen und Begriffe zu
Qualitätsmanagementsystemen."
"EN ISO 9001 [...] Diese Norm beschreibt modellhaft das gesamte
Qualitätsmanagementsystem [...] Die Norm betrachtet diese Prozesse
(Vorgänge) "
ich glaub, ich hab richtig geraten, obwohl ich natürlich hätte
schreiben müssen: "Gut, man muss seinen Darcs-Arbeitsprozess ja nicht
gleich ISO 9001 zertifizieren", da man ein Produkt/Werzeug selbst
natürlich nicht zertifiziert :-)
> > Das Frontend (also lokale GUI, "cvs" Kommando, ...) zählt eindeutig zum
> > SCM dazu, also wenn hier was on-the-fly umgewandelt wird, ist das IMHO
> > eindeutig eine SCM Funktion. Aber Details, klar.
>
> 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?
> > Beispiel:
> >
> > 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...
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 ;)
> 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$.
> 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.
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.
> > 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.
> > > > "Conflict Reduction"
> >
> > Nee, ich meinte, genau sowas würde ich schreiben, wenn ich keine Ahnung
> > ab und weiss, dass mein Leser auch keine Ahnung haben wird. Es sagt
> > nichts aus, klingt aber geil :-)
>
> Aus diesem Grund werden wohl auch so viele Abkürzungen verwendet. Die
> sagen dem Leser *noch weniger* und klingen *noch geiler*. ;-)
>
> "Supports HTML, XHTML, XML, XSLT, W3C, CVS, ..."
<!-- Was denn, kein .NET?! ..... SCNR :) -->
Ja, genau so ist das leider...
> > 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?
Oder warum mir ASN.1 besser gefällt?
> > und ausserdem will ich keinen Webserver mit einem völlig ungeignetem
> > Protokoll in so einem System haben. Hab das nie verstanden, wozu man
> > das brauchen soll. Weil es über Proxies geht? Muss man halt SOCKS
> > nehmen. Oder CGI-Irgendwas, was nicht für Menschen, sondern für
> > Tools ist. Wozu? Damit der Client auf'm Mobiltelefon läuft?
>
> So ungefähr arbeitet Darcs. Ja, CGI-Scripte sind meist besser. Ein
> Apache-Modul ist performanter.
>
> Mercurial bringt seinen eigenen Server mit, das halte ich für
> problematisch. Effizientes Protokoll (irgendwie aber auch HTTP,
> AFAIK), jedoch schlecht in andere Strukturen integrierbar.
Wieso, Unix lebt seit Jahren nur mit Files, ging auch ohne HTTP prima,
und Plan9 abstrahiert weiter von Files (nicht von XML Sprachen) - soo
falsch kann das Konzept wohl nicht sein, oder?
Mal ehrlich, gäbe es kein Java, wäre der XML-Hype nur halb so gross und
Software doppelt so schnell ;)
> 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?
> > Leider ist es ja auch nicht so einfach, wie ein SCM anzugucken. Muss ja
> > installiert werden, klar, aber wo kriegt man grosse Sourcen her?
> > Komplizierte Branches, die man Testweise mergt etc? Schon schwierig...
>
> Es gibt andere, die das gemacht haben. 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.
> 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...
Alles nicht so einfach :(
oki,
Steffen
--
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.
Mehr Informationen über die Mailingliste linux-l