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.
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 way we wouldn't need
to deprecate has_props. I'll try that today.
The problem I see with your solution though is that other dav clients
wouldn't get any speed improvements. If we removed DeltaV properties
from allprop requests, then we'd speed up every client, not just
subversion. It would be somewhat easier to implement I believe, so
I'll try it and see where I can get with it.
On 8/22/05, Ben Collins-Sussman <sussman@collab.net> wrote:
> As an experiment, I tweaked the ra_dav code to request only the 5
> properties it needs to fill an svn_dirent_t, rather than requesting
> *all* properties.
>
> The time it took to do an 'svn ls -R' against subversion own trunk
> URL went from about 30 seconds to 15 seconds.
>
> We're still not out of the woods entirely, though. svn_dirent_t has
> an annoying "has_props" boolean field that needs to be filled in.
> The current code loops through all the returned properties, and looks
> to see if any user-defined properties exist in the list. In order to
> complete the patch, we'll have to invent some new server-generated
> prop that indicates "this resource contains user-defined properties",
> and add it to our list of requested props. It also means that this
> speedup will only work against 1.3 mod_dav_svn servers; when talking
> to older servers, we'll have to still fetch *all* properties just to
> find out if user-defined props exist. :-(
>
> I guess another option is to play with deprecating the 'has_props'
> field. Maybe create an svn_ra_get_dir2() which doesn't fill in the
> has_props field by default, unless you explicitly ask it to. (Does
> any client actually use the 'has_props' field?)
>
> Here's the patch I was playing with. (You can play with it, but not
> that it's not complete or totally correct! svn_dirent_t->has_props
> is always 0.)
>
>
>
> Index: subversion/libsvn_ra_dav/fetch.c
> ===================================================================
> --- subversion/libsvn_ra_dav/fetch.c (revision 15883)
> +++ subversion/libsvn_ra_dav/fetch.c (working copy)
> @@ -915,6 +915,20 @@
> }
> +
> +/* the properties we need to fill in an svn_dirent_t, used by
> + svn_ra_get_dir(). */
> +static const ne_propname dirent_props[] =
> +{
> + { "DAV:", "resourcetype" }, /* kind */
> + { "DAV:", "getcontentlength" }, /* size */
> + { "DAV:", "version-name" }, /* created_rev */
> + { "DAV:", "creationdate" }, /* time */
> + { "DAV:", "creator-displayname" }, /* last_author */
> + { NULL }
> +};
> +
> +
> svn_error_t *svn_ra_dav__get_dir(svn_ra_session_t *session,
> const char *path,
> svn_revnum_t revision,
> @@ -961,7 +975,7 @@
> PROPFIND on the directory of depth 1. */
> SVN_ERR( svn_ra_dav__get_props(&resources, ras->sess,
> final_url, NE_DEPTH_ONE,
> - NULL, NULL /* all props */,
> pool) );
> + NULL, dirent_props, pool) );
>
> /* Count the number of path components in final_url. */
> final_url_n_components = svn_path_component_count(final_url);
>
>
>
>
>
>
>
>
> --
> 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 Mon Aug 22 20:33:57 2005