[linux-l] Re: VCS (was: Svannah, sf und berlios (was: sf und berlios))

Rocco Rutte pdmef at cs.tu-berlin.de
Mi Apr 5 13:20:12 CEST 2006


* Jan-Benedict Glaw <jbglaw at lug-owl.de>:
>On Wed, 2006-04-05 11:50:49 +0200, Rocco Rutte <pdmef at cs.tu-berlin.de> wrote:

>> Zum anderen ist es auch nicht sehr sinnvoll, ein verteiltes gegen ein 
>> zentrales VCS antreten zu lassen. Wenn alle Entwicklermaschinen im 
>> gleichen Netz hängen (also nicht über öffentliche Server gehen müssen), 
>> ist das Plus einen verteilten Systems auch schon wieder weg. (In so 
>> einem Fall kriegt man ein Backup, in dem man das 1 zentrale Repo sichert 
>> und nicht jede Workingcopy)

>Dazu muß man aber auch sagen, daß die zentral arbeitenden Leute oft
>nur _meißtens_ zentral arbeiten. Es wäre schon schön, wenn man mal zum
>Kunden fährt, noch SCM-Vorgänge machen zu können, ohne erst via
>OpenVPN o.ä. den Weg zum zentralen Server zu finden...

ACK. Die Optimale Lösung[TM] wäre natürlich Userspace VFS, dass man 
durch SSH tunneln kann.

Aber weil subversion ja schon etwas mehr Kompromisse hin zu Verteilung 
eingeht (bzw. für manche Operationen nicht zwingend den Server braucht), 
sind es kleine technische Details, die in solchen Szenarien richtig 
schmerzen.

Zum Beispiel könnten sie beim Anlegen des Repos ja einfach eine lange ID 
zufällig/halb-zufällig ausknobeln, damit man Repos auf andere URLs quasi 
live migrieren kann. Da könnte man unterwegs mit einer SSH-Verbindung in 
das Netz mit dem Server einfach auf remote_host->127.0.0.1->port 
umstellen.

Ich habe mir auch schon überlegt, ein Shellscript für sowas zu 
schreiben, dass aus einer aktuellen Workingcopy lokal ein neues Repo 
anlegt, dann die diffs rausrechnet und als neue Revision dahin 
eincheckt. Daraus könnte man dann wieder Patches erzeugen, die man 
später in den Upstream zurückschickt.

   bye, Rocco
-- 
:wq!



Mehr Informationen über die Mailingliste linux-l