Re: ideas to make svn update faster.

Greg Hudson wrote:
> On Sun, 2005-05-08 at 18:00 +0200, Thomas Zander wrote:
>
>>Do I understand correctly that the local filesystem access is different
>>based on which network layer I choose?
>
>
> Yes. The DeltaV protocol (which we sort of follow, but not very well)
> requires us to use a server-provided "version-resource URL" for each
> file and directory in the working copy. In practice, when talking to a

But only if you actually want to access that version, right?

> Subversion server, these URLs follow a very specific form, but in theory
> they could be arbitrary. We have a mechanism called "wcprops" which we
> use to cache these version-resource URLs in the working copy so that we
> don't have to re-fetch them for each operation.

This shouldn't be an issue as long as the SVN client talks to an SVN
server because they could in theory share the knowledge how to compute
these URIs.

> It has long been my position that we should give up on DeltaV (which is
> a failed standard, in my opinion, and one that doesn't fit our
> architecture) and consider ourselves to be talking a private versioning
> protocol over HTTP/DAV. As part of that, we could feel free to

I do agree that the current situation is frustrating. For instance, none
of the currently available DeltaV clients works with a Subversion server
because it fails to implement lots of mandatory stuff.

On the other hand, I do disagree that dropping the goal of becoming
RFC3253 compliant would be good :-).

> synthesize version-resource URLs, which would let us ditch the wcprops
> mechanism, which would eliminate the discrepancy between ra_dav and
> ra_svn in working copy performance.

As far as I can tell, you can do that easily as long as your client only
needs to work with SVN servers.

> Some developers agree with me and some don't; regardless, we haven't
> gone in that direction as yet.

Best regards,

Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org