[linux-l] Re: VCS

[Steffen Dettmer]

* Volker Grabsch wrote on Sat, Apr 22, 2006 at 23:11 +0200:
> So sieht das in Subversion auch aus.

(OK, hab ich verstanden, da es Keywords genauso gibt).

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

Macht man ja nicht über jede Datei einzeln sondern über ein Tag - wenn
man denn eines hat. Im Beispiel hab ich jedenfalls nur eine Datei
genannt :) Sonst wird's nervig mit CVS, auf jeden Fall.

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

Ja, bei freier Software gibt es auch etliche andere Probleme nicht so)

> > Laut Wikipedia:
> [...]
> 
> Cool, Wikipedia beschreibt diese Standards? Wusste ich gar nicht.

Wieso, haste schon was gefunden, was Wikipedia /nicht/ beschreibt?

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

Ja, Du würdest dafür sorgen, OK. Vermutlich bist Du kein Manager?

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

Will man doch aber nicht. Auf einem Gerät möchte die Seriennummer auch
draufkleben und nicht nur auf einem Beipackzettel stehen.

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

Ja, OK.

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

Muttu Dir ein "alias" machen. Was macht CVS, wenn zwei widersprüchliche
$Header: drin sind? usw. Nee, lieber einfach halten, CVS hat auch so
schon genug Bugs :)

> Man könnte sich diese Datei(en) in sein Verzeichnis packen, macht
> "cvs di", und sieht nur die eigentlichen Änderungen. 

So musste sie in ein Verzeichnis packen und diff -r <name> machen, man
überlebt's :)

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

Ja, mit CVS Sandbox nehmen, "update -r <name>", dann Files drüber, dann
"update" dann hat man trunk mit den Änderungen, genau.

> Und dafür könnte man diese $Header: ...$ dann IMHO gut gebrauchen, aber
> eine Kodierung im Dateinamen würde es genauso tun.

NEIN, eben nicht :-) Du schickst doch DasModulInVersion1.0.c und
bekommst volkers.c zurück :)

jaja das war erfunden, stimmt :)

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

Ich finde, in der Datei ist "solider".

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

Ja, und hintem ihm stehen bleiben, das ist klar.

> Immerhin kann es genauso passieren, dass er die Datei umbenennt, wie
> dass er den $Header: ...$ ändert.

Einigen wir uns auf "/fast/ genauso"? :)

Aber soooo viel Aufriss wollte ich mit meinem Beispiel nicht machen, ich
wollte nur zeigen, wo $Name$ hilft.

> > Ja, aber auch mit Keyword-Expansion bleibt das Reproduzierbar.
> 
> Ja, eben. Eine Kodierung im Dateinamen wäre damit genauso ISO-9001
> zertifizierbar, oder?

Ja sicher! Aber dann wird das diffen und das Anpassen der Makefiles
nervig :)

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

Es ist eine descriptive Programmiersprache, also ja, textbasiert,
formatfrei, so wie C und Perl und Java usw.

> Ein Binär-Protokoll finde ich nämlich nicht sonderlich erstrebenswert.
> Zahlen sollten übers Netzwerk IMHO als "1235363.23" kodiert werden,
> also menschenlesbar.

Warum menschenlesbar? Ein Mensch kann sowieso kein Ethernet-Frame lesen.
Und wenn ich Dir die von einem nicht ganz schlechten Tool kommentierten
(!) XML (!) Logfiles mit geparsten (!) und kommentierten (!)
Binärnachrichten zeigen würde (dürfte ;)), würde das viel viel mehr
sagen, als so ein Format - und immer noch ca. nichts :)

Die Kodierung ist halt egal. Ob Du Deine ASN.1 Strukturen mit C oder
Java als XML oder DER überträgst, legt nicht ASN.1, sondern sogenannte
Kodierungsregeln fest. Sehr bekannt ist DER: Distinguished Encoding
Rules (lassen sich am einfachsten implementieren). Steht auch ein Link
zur ITU in der Wikipedia :)  Es gibt auch XER, XML Encoding Rules, da
kommt dann halt XML bei raus.

> Für Strukturen gibt's YAML und JSON, aber gegen XML hab ich auch nichts,
> wenn man die Vorteile gebrauchen kann. 

XML verhält sich zu Schema/DTD
wie
DER/XER zu ASN.1

XML ist damit ne Art "Spezialfall" "von ASN.1".

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

Und nur geringfügig grösser, als geschicktes DER ;)

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

Und warum hat der kein Webstart?

Na, wie auch immer, ich bin überzeugt, dass eine Einstiegshürde wichtig
ist, sonst kommen die AOL'er und versauen das dann auch ;)

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

Klick auf URL, JNLP-File, Fenster - oder? IMHO /der/ Sinn von Java - das
bringt IMHO wirklich was. Und ist schnell. Nicht so schnell wie lokales
C, klar, aber ich meine so "als Kompromiss". Und Du musst nix
installieren oder so.

> |     http://lwn.net/Articles/151624/                 

Ach so, ja, hatte ich dann doch gelesen! Aber empfand das weniger als
Gegenüber als vielmehr als Nebeneinanderstellung ;)

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

Nee, schon klar, aber da spielen ja nicht nur "technische Performance"
eine Rolle! Wie reagiert man auf komische Leute (bei Opensource nimmste
die Patches halt nicht) usw. War auch keineswegs negativ gemeint!

Danke Euch allen für die vielen Informationen und die Zeit, die ihr
investiert hab, um mir die Thematik näherzubringen! DANKE!!

oki,

Steffen

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