Branko Čibej wrote:
> Blair Zajac wrote:
>> David Glasser wrote:
>>> On Thu, Nov 6, 2008 at 10:36 AM, Blair Zajac <blair_at_orcaware.com> wrote:
>>>> Greg Hudson wrote:
>>>>> On Thu, 2008-11-06 at 09:28 -0800, Blair Zajac wrote:
>>>>>> Where I'm coming from is treating the svn_fs.h API as a versioned
>>>>>> filesystem, ignoring the version control aspects of svn, so making
>>>>>> available via HTTP could be useful and have interesting applications
>>>>>> available in the future.
>>>>> Subversion's architecture has never included making the FS interface
>>>>> available over the network. There's no reason someone can't make a
>>>>> network binding to the FS layer (as you did), but that's not in any
>>>>> shape, or form the job of the Subversion RA layer.
>>>> There's two different things as I see it, correct me if I'm wrong.
>>>> the RA layer in C which will use the protocol. This won't change
>>>> and I'm
>>>> not suggesting modifying it. I'm just saying, make the new protocol
>>>> of making the FS interface available over the network. Other people
>>>> write their own code on top of the protocol separate from the RA layer.
>>> That sounds like a great third-party project, but I don't see why it
>>> has any business being part of the already-overextended subversion
>> I'm not saying we write that other code, I'm just saying the protocol
>> should support it.
> 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
> 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.
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-08 18:59:22 CET