[linux-l] Re: VCS

[Rocco Rutte]

* Volker Grabsch <vog at notjusthosting.com>:
>On Tue, Apr 18, 2006 at 04:23:31AM +0000, Rocco Rutte wrote:
>> * Volker Grabsch [06-04-14 13:36:53 +0200] wrote:
>> 
>> >Seit Ewigkeiten gibt's wiegesagt schon den Feature-Request für
>> >Subversion, dass es Merges verwalten soll. Vielleicht haben sie das
>> >ja in der neuren Version implementiert, weiß ich nicht. Ist aber auf
>> >jeden Fall keine neue Kritik.  :-)
>> 
>> Die Implementierung wird relativ kompliziert/umfangreich, weil man dafür 
>> merges (und damit Branches) neu für subversion konzipzionieren muss.
>> 
>> Subversion kennt ja nur Kopieren von Dateien, dass man als Branch oder 
>> Tag interpretiert, aber es ist eben nur ein Fake oder generisch oder wie 
>> auch immer man es nennen mag.

>Das ist richtig, aber nicht das Problem. Bei CVS hätte ich dieselben
>Sorgen.

Ich kenne CVS so genau nicht, aber bei subversion ist IMHO genau das 
das Problem.

Vielleicht verstehen wir uns ja falsch; deshalb schreibe ich nochmal 
genauer, was ich meine.

Es gibt ein Repository und darin trunk/, branches/a und 
branches/b. Das sind alles nur Dateien/Verzeichnisse und subversion kann 
nicht wissen, dass alle 3 das selbe Projekt in verschiedenen Zweigen 
repräsentieren. Es müsste beim Anlegen von branches/a und branches/b aus 
trunk/ sich die Revisionsnummern merken und mitverfolgen, wann welcher 
Diff von welcher Branch in welche Branch geht.

Das im Prinzip nicht kompliziert (mit svnlook kann man das parsen und 
selber mitschreiben). Da aber subversion eben nur Dateien kennt, müsste 
man ihm irgendwie mitteilen, dass die 3 Verzeichnisse das selbe Projekt 
repräsentieren. Und IMHO liegt das Kernproblem genau darin, subversion 
diese Logik für die Erkennung von Dateien/Verzeichnissen als "Branch" 
mitzuteilen.

Man könnte ja auch eine Branch aufmachen, die leer ist, um das Projekt 
vom scratch neu zu schreiben. Subversion müsste den Zusammenhang also 
auch ohne eine Kopie von trunk/ merken können und darf nicht nur auf 
Kopien losgehen.

Andererseits ist nicht jedes Kopieren eines Verzeichnisses eine neue 
Branch, die es beobachten soll.

Bei git ist das einfacher. Jeder Commit bekommt eine ID und der aktuelle 
Stand einer Branch ist dann die letzet committete ID. Außerdem bekommt 
jeder Commit seine vorherigen IDs (Mehrzahl) mit, aus der er hervor 
gegangn ist (bei subversion: $revision-1). Will man dann Branch1 nach 
Branch2 mergen, geht man die Liste aller Parent-IDs durch und sucht eine 
Übereinstimmung (das war das Anlegen der Branch). Von da an kann man 
dann bis zur letzten ID die jeweiligen Diffs eines Commits übertragen 
und fertig.

Bei subversion müsste man das alles irgendwie mit einem Skript ermitteln 
und sich Listen von Revisionsnummern erstellen, mit denen man die Diffs 
erhält. Weiss man die Logik (also das Mapping von Verzeichnis auf eine 
Branch), kann man das Skript entsprechend bauen. In den meisten Fällen 
wird das Standardlayout trunk-tags-branches auch gut genug sein. Aber es 
geht eben nicht allgemein und generisch, weil das Konzept Branch nicht 
eingebaut ist.

>> Subversion müsste anfangen zu raten (bzw. konfigurierbar sein), wann 
>> eine Kopie einer Datei/eines Verzeichnisses eine neue Branch ist und die 
>> selbe Logik bei Commits anwenden.

>Das muss es sowieso, wenn die Kommunikation "stateless" ist, was ich
>ja will.

>Beim Holen der Datei die Revision-Nummer (bzw. allgemein Zusatz-
>Infos zur Version) mitzuliefern, und diese beim Hochladen wieder
>mit anzugeben, sollte nicht das Problem sein.

Hmm. Eine Kopie in Subversion ist eine "cheap copy", also copy-on-write. 
Wenn man trunk/foo.c hat und trunk/ nach branches/a kopiert und dann 
branches/a/foo.c ändert, dann ist das für subversion eine normale Datei, 
gegen die ein diff committed wird. Das hat mit dem "Original" 
trunk/foo.c nichts zu tun (außer die History, wofür die Metadaten des 
Copy ja nur gebraucht werden).

>Mir schwebt sogar vor, dass nicht die Datei, sondern nur ein Patch
>wieder zurückgeladen wird, aber das macht die Sache auf Client-Seite
>unnötig schwierig.

Subversion überträgt nur diffs.

>Will man unbedingt zustandsbehaftete Kommunikation, dann ist es erst
>recht ein leichtes, die Versionsnummer sich auf Serverseite zu merken.

Mit der Revisionsnummer ist es aber nicht getan.

   bye, Rocco
-- 
:wq!