[linux-l] Re: VCS

[Rocco Rutte]

* Steffen Dettmer <steffen at dett.de>:

>> > Ja, und es geht einfach, weil in dem exp-Branch keiner was anderes
>> > geändert haben sollte. Im trunk kann man selten "einfach so" reverten.
>> 
>> Doch, schon. Aber nur in Changeset-basierten VCS.

>Ich glaube das nicht. Wie soll das funktionieren? Mit einem "diff" tool,
>dass C Quelltext gramatikalisch analysiert oder wie? Der erste führt ne
>neue Variable ein, der zweite initialisiert sie nicht direkt, sondern
>über eine refaktorisierte Funktion, der dritte benennt sie um und der
>vierte baut eine Prüfung und ein logstatement ein. Wie willte jetzt die
>zweite Änderung (und nur die) reverten?!

In dem man den zweiten Commit revertet? ;-)

Klar, das ist sinnlos, weil dann der Code kaputt ist, aber dafür kann 
die Versionskontrolle nichts.

Ich habe noch nicht genau herausgefunden, was mit "Changeset" genau 
gemeint ist, aber ich denke mal, dass ein Commit atomar ist, mehrere 
Dateien betrifft und nur als ganzes existiert (ein Commit in git, eine 
Rivision in Subversion, etc).

Da ist ein revert mit einem Changeset-basierten VCS natürlich einfacher 
statt sich für deine 2. Änderung in CVS alle betroffenen Dateien 
rauszusuchen.

Vor allem, weil ein revert mehr ist als nur 'diff | patch -R', weil die 
meisten VCS auch rename können.

>> Darcs z.B. kann das. Aber nur, wenn die darauffolgenden Patches unabhängig
>> sind. Bei neuen Features ist das aber i.d.R. der Fall.

>"unabhängig"... Na, /dann/ kann CVS das auch. Da reverted man über ein
>Datum, ein Tag (oder alt zwei) oder notfalls über Revisionsnummern (oder
>commit-Ids oder wie auch immer das SCM sowas nennt) einfach per
>textueller zeilenweisen Patcherei, klar. Gut, bei CVS muss man leider
>händisch taggen und diverse andere Nachteile machen sich breit, gerade
>bei weit verstreuten Änderungen, aber /wenn/ man das denn mal braucht,
>kriegt man es hin.

Es ist glaube ich einfach "nur" umständlich, also es geht schon, klar.

>> So kann man dann die verschiedenen Branches einfach als verschiedene
>> Zusammenstellungen von Patches (d.h. changesets) betrachten.

>Ja, OK, das ist bei CVS ja (mit etlichen Buch füllenden Einschränkungen)
>auch in etwa so.

Nein, nicht wirklich.

Streng genommen gibt es in zum Beispiel git ja nichtmal Repositories 
sondern nur eine Welt mit quasi allem Code unter Versionskontrolle.  
Jeder commit ist ein benannter (Log) Diff gegen einen Vorgänger (wenn 
der leer ist halt der erste). Eine Branch ist konzeptionell nur ein 
symbolischer Name für einen Commit, der bei jedem Commit der Branch 
akualisiert wird (zum ersten mal hatte ich git mit 0.6 oder 0.7 benutzt, 
da musste man die ID, die man beim Commit bekommt, noch manuell 
speichern sondern kam man an den Commit nicht mehr ran. Jetzt machen das 
Gott-Sei-Dank Shellscripte ;-).

Beispiel: in trunk gibt es den letzten Commit 'a', wobei das wohl 
identisch mit "Changeset" ist. Davon macht man eine Branch auf und 
committet etwas als Commit 'b' mit Vorgänger 'a'. Der symbolische Name 
für die Branch verweist auf 'b' als letzten Commit, der für trunk 
weiterhin auf 'a'. Je nachdem wohin man committed, werden die letzten 
Commits aktualisiert. Wenn man weiter in trunk committed, dann wird der 
Pointer für den letzten Commit in trunk jeweils angepasst (für die 
Branch bliebe er gleich, d.h. man bekäme immer 'b') usw.

Das ganze ist intern ein gerichteter und azyklischer Graph mit Commits 
als Knoten. Die ganzen Branches, Tags _und_ verschiedene Repositories 
sind nur pointer für solche Commits und man kann beliebige dieser 
Untergraphen verschmelzen.

Das ist hat nicht mehr wirklich etwas mit CVS/RCS zu tun...

   bye, Rocco
-- 
:wq!