Branko Čibej wrote:
> 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).
Maybe should take a step back. I'm not looking for any remote svn filesystem
you can mount or even directly use today. I just think having an RPC API were
if someone was interested, they could do remote RPC calls to an API that mirrors
svn_fs.h and svn_repos.h. Currently we have a higher level API that mirrors the
RA layer.
In our case, I'm using Ice (www.zeroc.com), which is very similar to CORBA and
has a similar IDL file. I've defined an AbstractTime interface which has a
RevisionTime and a TransactionTime derived from it and those interfaces have all
the path operations from svn_fs.h and svn_repos.h. There's also a Repos
interface which has methods that find or create RevisionTime and a
TransactionTime objects.
>>> 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.
I think there's some misunderstanding here. I'm not suggesting changing the RA API.
I see two ways to do this.
One, write a HTTP protocol that mirrors the RA API. This puts most of the
coding work in mod_dav_something to map RA down to svn_fs.h.
Two, write a HTTP protocol that mirrors svn_fs.h and svn_repos.h. Then the
mod_dav_something layer is very straight forward and the client side RA code
needs to do more of the work mapping RA down to basic calls.
Blair
---------------------------------------------------------------------
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 23:22:38 CET