RE: 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/ sub

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: cmpilato@apache.org [mailto:cmpilato@apache.org]
> Sent: woensdag 23 juni 2010 3:22
> To: commits@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