[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: Blair Zajac <blair_at_orcaware.com>
Date: Sat, 08 Nov 2008 09:59:01 -0800

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
>>>>>> this
>>>>>> 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
>>>>> way,
>>>>> 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.
>>>> There's
>>>> 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
>>>> capable
>>>> of making the FS interface available over the network. Other people
>>>> can
>>>> 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
>>> core.
>> 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
svn repository.

> 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

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.