> -----Original Message-----
> From: cmpil...@apache.org [mailto:cmpil...@apache.org]
> Sent: woensdag 23 juni 2010 3:22
> To: comm...@subversion.apache.org
> Subject: svn commit: r957094 - in /subversion/trunk: ./
> subversion/include/ subversion/libsvn_client/ subversion/libsvn_fs/
> subversion/libsvn_fs_base/ subversion/libsvn_fs_base/bdb/
> subversion/libsvn_fs_fs/ subversion/libsvn_ra/
> subversion/libsvn_ra_local/ subv...
>
> Author: cmpilato
> Date: Wed Jun 23 01:22:00 2010
> New Revision: 957094
>
> URL: http://svn.apache.org/viewvc?rev=957094&view=rev
> Log:
> Finish issue #3661: RA get-locks inefficiencies.
>
> Add depth support to the process of querying repository locks in the
> repository and RA layers for the sake of performance. Prior to this
> change, 'svn ls -v SOME_PATH' (non-recursive) asked the repository for
> the locks on all paths in and under SOME_PATH (fully recursive),
> resulting in potentially far more information being transmitted across
> the network than is necessary.
Not really connected to resolving this issue, but I think this ra api can be
optimized a bit further with the knowledge we build with the wc-ng code.
Currently the locks are always returned as full filesystem paths (in
'/trunk/path/to/file' style) instead of as a session relative path (e.g.
path/to/file). Switching to session relative paths would allow using the
svn_relpath_*() apis on the files and would (slightly) reduce the amount of
traffic.
In combination with this change we don't even need feature negotiation: On the
client it will be easy to detect which style of paths is returned by just
checking if the first path starts with a '/'. The server can switch to relative
paths when a depth is passed on the request.
Bert
