[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: HTTP protocol v2: rethunk.

From: Branko Čibej <brane_at_xbc.nu>
Date: Sun, 09 Nov 2008 02:47:03 +0100

Blair Zajac wrote:
> Branko Čibej wrote:
>> Frankly, that seems like a complete waste of time to me. Sure a
>> "versioned remote filesystem" sounds like an interesting piece of
>> infrastructure, but it's utter nonsense to try to invent a new protocol
>> for that. Much better to do this as a local layered FS (e.g., a FUSE
>> layer on Linux that talks to a local repository) and then expose that to
>> remote clients via any of the myriad mature remote-filesystem servers.
> I disagree. I've already written it once in Ice and it's the backend
> of an distributed versioned asset management system for a visual
> effects company. I wish I didn't have to write a new RPC layer.
> I'm not aware of any remote-filesystem servers that expose the time
> aspect of a svn repository.

There are other ways of exposing the time component through a remote
filesystem. One that I used long ago was to have a separate "control"
share where writes to magic files represented commands. Custom FSCTLs
come to mind, or even the brute-force method of exposing all of history
in one tree -- that last admittedly being the most horrible option, as I
know from experience. Frankly we'd never have been able to do the
remote-fs functionality in time if we hadn't had one available already
(that was back in 1995, by the way).

>> That said, the subversion repository is not really suitable as a FS
>> back-end without a lot of fiddling and additional caching, partial
>> writes to versioned resources would be a nightmare.
> Yes, I wrote that also, but in the middle-tier, not the svn backend.
> Given that everything is immutable in a svn repository makes caching
> very easy.

I wrote all of the above too, twice, so I know whereof I speak. :) I
still maintain that doing a remote filesystem from scratch is a waste of
time, and that supporting that in a RA layer "because it could be
potentially useful" is an even bigger waste of time. Let's not loose
sight of our goals here.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-09 02:47:24 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.