[linux-l] Re: VCS

[Volker Grabsch]

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 ist eben eine andere Herangehensweise: Änderungs-Blöcke sind die
kleinsten Einheiten und sind indentifizierbar. Versionen ergeben sich
unmittelbar daraus (als Mengen/Zusammenfassungen von Changesets).

Ich verstehe daher nicht dein Problem.

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

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

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

Gut, eine Frage des Entwicklungs-Modells.

> Bei CVS gucke ich in $Name$. Ist es leer, wurde kein Tag benutzt,
> schlecht, aber macht nichts, guckt man in $Header$. Man bekommt es in
> jedem Fall identifiziert (da nach unseren Entwicklerregeln sowohl Header
> als auch Name drinstehen muss - sonst kann man gar nicht einchecken).
> 
> Ich kann also eine Sandbox so updaten, dass die Datei passt. Dann
> kopiere ich die drüber. Nun kann ich cvs diff benutzen. Ich kann nun auf
> die neueste Branchversion oder sonstwohin updaten und einchecken. Oder
> ich könnte neu branchen und einchecken (aber das hab ich noch nie in
> dieser Kombination gebraucht).

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.

Die Identifikation ist sehr einfach, nur die "1054" plus Datei/Verzeichnis-
Namen. Du machst einen "svn update -r1054", kopierst den Krempel rein,
der Rest wie bei CVS.

> Wie macht man sowas, wenn die Datei vom SCM gar nicht automatisch
> markiert wird?

Die Frage ist zu Datei-zentriert. Änderungen können sich auf mehrere
Dateien beziehen. Zentrale Nummern helfen da.

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)

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

Vielleicht kann hier jemand etwas zu Mercurial oder GIT sagen.

> > > "Conflict Reduction" liest sich auch wie aus'm Marketing-Handbuch,
> > > mmm...
> > 
> > Ein Marketing-Text würde sowas zwar auch sagen, sich dabei aber auf
> > menschliche, nicht technische, Konflikte beziehen.  :-)
> 
> 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, ..."

> > > Vielleicht mit "praktischem Hintergrund"? Ich mein, ne gute Idee
> > > nützt ja nix, wenn es in Produktion Probleme geben kann. Schwieriges
> > > Thema jedenfalls. Ich glaube, daher verwenden viele CVS.
> > 
> > Ich denke, selbst Subversion bereitet viel weniger Probleme als CVS,
> > und ist in nahezu jeder realen Anwendung die bessere Alternative. Ob
> > dies aber den Umstiegs-Aufwandt rechtfertigt, ist natürlich ne andere
> > Frage, die jede Gruppe für sich klären muss.
> 
> 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?

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

Ein CGI-Script, das sowohl für Menschen als auch für Tools gut bedienbar
ist, ist IMHO das Optimum an Interoperabilität.

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

Schönes reales Beispiel aus dem "echten Leben". Die Kernel-Quellen sollten
jedenfalls deine Ansprüche an Größe und Branches erfüllen.


Viele Grüße,

    Volker

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