[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn list -R of medium-size repository takes 10 hours.

From: Jean-Marc Godbout <jmgodbout_at_gmail.com>
Date: 2005-08-22 20:54:57 CEST

Yes, I was calmly eating my cheerios when I realised that I wasn't
thinking about backwards compatibility.

1. If we simply remove all the DeltaV props, then we are preventing
any old clients from connecting as they expect Checked-in to be there.

2. If we make the clients query for the has_props, then we would need
to handle the case of the older server. This is fixable. If we get a
404 for that property, then we do an allprop and request everything -
using the old way to determine has_props. This would be much slower,
but not break any existing functionality.

Solution 2 would mean that only clients and servers that are newer
than *now* would still be slow. However, they would all work - And
newer clients and servers would be faster. It seems like solution 1
would be better suited to a major upgrade.

On 8/22/05, Ben Collins-Sussman <sussman@collab.net> wrote:
> (Please keep the dev@ list cc'd on all discussion.)
> On Aug 22, 2005, at 1:32 PM, Jean-Marc Godbout wrote:
> > Oh, I'm sorry if I was unclear. Issue 2151 has a reference to RFC
> > 3253, Section 3.11 which states that DeltaV properties SHOULD NOT be
> > returned in an allprop request (for efficiency reasons actually).
> > "Checked-in" is a DeltaV property and shouldn't be returned in an
> > in an allprop request.
> >
> Wow, I had no idea! We're really out of date. When we started
> subversion 5 years ago, the DeltaV spec was much different (and only
> an early draft). Thanks for pointing that out!
> As you suggest, it's probably a good idea to follow this part of the
> spec. It would make generic DAV clients faster... such as when
> mounting a Subversion repository in Windows or OSX. Unfortunately, I
> suspect it will require a change to mod_dav, not mod_dav_svn. I
> don't actually think that logic is under subversion's control.
> > Your suggestion to only query for props that we would want also works
> > as it eliminates the most costful properties to generate. What about
> > adding a new prop on the server called has_props that would return the
> > correct value and we could query for that.
> That's exactly what I suggested in my previous mail. :-) The
> problem is, what happens when you run 'svn ls' against an older
> server, and you get a 404 on that particular new property? How are
> you going to find out if user-defined props exist? That's the
> problem which needs discussion.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 22 20:56:16 2005

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.