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