[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