[linux-l] Re: VCS

[Volker Grabsch]

On Mon, Apr 10, 2006 at 02:33:34PM +0200, Rocco Rutte wrote:
> * Volker Grabsch <vog at notjusthosting.com>:
> 
> >Darcs ermöglicht sogar, dass man sich alle "Hunks" (Änderungsstellen)
> >innerhalb der Dateien ansieht, und bei jedem "commit" (dort: "record")
> >auswählt, welche Hunks aus welchen Dateien man haben will. Das erleichtert
> >es ungemein, saubere Patches zu erstellen.
> 
> Ich für meinen Teil verstehe den Sinn dahinter nicht. Klar, wenn man aus 
> einer Edit-Session für eine Datei zwei Commits machen will hilft es 
> vielleicht, aber es bei mir nicht die Regel.

Bei mir schon. Und ich kenne auch viele andere Programmierer, denen es
so geht (deshalb hab ich es so ausführlich beschrieben). Sicher nicht
bei jedem "record" ("commit"), aber jeder dritte reicht ja auch schon
...

> Ich hatte mich mit darcs 
> nicht sehr intensiv beschäftigt, aber 24.000 solcher Hunks für ein 
> quasi-Auto-edit waren mir echt zu krass (und ein Prompt nach 30 Minuten 
> für den ersten Hunk auch).

Das ist ja was völlig anderes. Die Performance spricht eindeutig gegen
Darcs, keine Frage.

Aber dsa Konzept greift auch hier super: Du kannst schließlich mit einem
schlag alle Hunks einer Datei akzeptieren. Sowas ähnliches, wenn auch im
kleineren Rahmen, hatte ich mit ner bearbeiteten SVG-Datei. Da hatte ich
jedoch keine Performance-Probleme, die war relativ klein, aber eben 'zig
Änderungen ... klein Problem!

> >Kurz: Ich sehe hier keinen ernsthaften Vorteil von CVS gegenüber
> >Subversion, sondern eher das Problem, dass die von dir geschilderten
> >Entwickler allgemein mit ner Versionskontrolle noch nicht sauber
> >genug umgehen.
> 
> Das mag sein. Aber es ging ja eigentlich auch nicht um Log-Messages 
> sondern Revisionsnummern. Und da finde ich die Revisionsnummer pro Datei 
> von CVS nunmal nicht generell schlechter als die eine pro Commit bei 
> Subversion. Es kommt halt drauf an.
> 
> Der Vorteil an einzelnen Nummern pro File bei CVS ist zum Beispiel, dass 
> man schon an der ID die Branch erkennen kann und im Vergleich zu anderen 
> Dateien, ob relativ viel oder wenig geändert wurde. Das muss man sich 
> bei subversion erst alles mühsam zusammen suchen.

Naja, "svn log DATEINAME | wc -l" ist IMHO sogar ein noch besserer
Maßstab, weil das Anzahl der Zeilen der Log-Einträge mitzählt.

Ich selbst habe mich nie für eine ganz bestimmte Datei interessiert,
und hatte für die Datei-spezifischen CVS-Nummern entsprechend keine
Verwendung.

Bei den Subversion-Nummern hatte ich zumindest den Nutzen, dass ich
bestimmte Versionen direkt mit einer Nummer ansteuern konnte, ohne
gleich extra viele Tags dafür zu definieren.

> >Na gut, Tags und Branches, darum kümmert sich der Maintainer, also
> >i.d.R. nur eine einzige Person im ganzen Team. Die "tägliche Arbeit"
> >erfordert viel weniger Hintergrundwissen.
> 
> NACK. Ich mache bei allen nicht-trivialen Änderungen Branches und 
> manchmal auch Tags (was ja unter subversion das gleiche ist), und 
> committe größere Änderungen per merge dann "irgendwann".

Das wusste ich nicht. In diesem Fall ist Subversion wirklich nicht
zu empfehlen, und du wirst von Darcs/Mercurial/GIT enorm profitieren!

Da hat nämlich jeder seine private Liste an Patches, kann die ansammeln
lassen, und mit einem schlag in ein anderen Repository senden ... oder
auch nur bestimmte Patches.

Ich bekomme mittlerweile den Eindruck, dass diese changeset-basierte
Sichtweise eigentlich die natürliche Sicht ist. Von daher könnten
changeset-basierte VCS den Anfängern vielleicht doch eher zugänglich
sein.

> Wenn ich mir so durchlese, was ich schreibe, klingt es ja fast so als ob 
> ich ein dezentrales oder Patchset-orientiertes VCS haben sollte. ;-)

Meine Worte.  ;-)


Viele Grüße,

    Volker

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