[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