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

Re: [PATCH] Fix for issue 2151 "'svn ls' is slow over ra_dav"

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-09-01 20:54:11 CEST

On Sep 1, 2005, at 12:19 AM, Jean-Marc Godbout wrote:
>
> 1. Add the supports_deadprop_count variable to the session. If 2
> "svn ls" are done in the same session, then the second time around
> you wouldn't need to do that discovery propfind. This also
> simplifies #2.
>
> 2. Make an OPTIONS request to get the server options, then set the
> variable in the session. "ls" would then always know and wouldn't
> need to do the propfind.

I do like the idea of using OPTIONS -- it's very purpose is to
discover features, and so we'd be doing the right thing by making use
of it. I also like the idea of caching the feature's existence in
the svn_ra_dav_session_t.

>
> Another change that would require an upgrade would be to make the
> server be more DeltaV compliant by simply not sending any DeltaV
> props on an allprop request (as described in issue #2151). This
> would mean that all older clients couldn't do "ls"s against patched
> servers...

You keep saying this, but why do you believe it to be true? If the
server stops sending DeltaV props in response to <allprop> requests,
which svn client commands break? And why?

>
> Fixed. Also, is there a way to have the build fail if the code
> isn't C89 compliant?
>

We used to use a gcc flag to enforce C89, but it caused some other
side-effects, so we removed it. I can't remember the details...?

Haven't reviewed your new patch yet... will do so next.

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 1 20:56:02 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.