[linux-l] Re: VCS

Rocco Rutte pdmef at cs.tu-berlin.de
Mo Apr 10 14:33:34 CEST 2006


* Volker Grabsch <vog at notjusthosting.com>:
>On Sat, Apr 08, 2006 at 03:15:39AM +0000, Rocco Rutte wrote:
>> * Volker Grabsch [06-04-05 15:27:27 +0200] wrote:

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

>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. Ohne Sachen wie 
$HeadURL$ hat man bei Subversion ja schon verloren wenn man größere 
Bäume mit verschiedenen Branches hat.

>> >Sind Darcs,Mercurial,QIT schwerer zu verstehen als Subversion?
>> >(für einen Anfänger)
>> 
>> Weiss ich nicht. Woran will man das auch messen? Zu allen Systemen 
>> sollte man die Doku lesen und will schnelle Einstiegshilfen finden.  
>> Danach wird sich früher oder später dann abzeichnen, ob man selbst mit 
>> den Macken des benutzten Systems (und alle haben ja welche ;-) leben 
>> kann oder nicht.

>Dennoch ist es ein Unterschied, ob man immer seine Änderungen mit
>dem Server synchron hält, oder ob man eine Liste von Patches bei
>sich hat, die regelmäßig auf dem Server landen.

Ich habe jetzt im zweiten Anlauf endlich svm (subversion mirror) zum 
Laufen gekriegt und damit hat sich das Problem mit den lokalen 
Änderungen ja auch schon erledigt.

>Letzteres ermöglicht Arbeitsweisen, die z.B. mit Subversion undenkbar
>kompliziert wären. Andererseits muss man sich erst daran gewöhnen.

ACK.

>> Ich denke, dass es für einen wirklichen Anfänger eher schwerer ist zu 
>> verstehen, wann man warum überhaupt ein VCS braucht und so komisches 
>> Zeugs wie Tags und Branches... ;-)

>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". Ich mache kaum 
noch etwas "Live" in trunk/, weil es passiert, dass Sachen nicht 
funktionieren und dann ist es gerade im Team schlecht, wenn nichtmal 
mehr trunk/ halbwegs geht. Dann sind alle blockiert bis "jemand" trunk/ 
wieder repariert hat. Oder man sitzt gerade an einer größeren Änderung 
und jemand kommt mit einem einfachen Fix, der schnell rein muss (ich 
weiss, darcs und hunks).

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

   bye, Rocco
-- 
:wq!



Mehr Informationen über die Mailingliste linux-l