lock report inefficiencies

[km...@rockwellcollins.com]

When debugging some repository performance problems, I narrowed it
down to repositories with large numbers of locked files.  For example,
if I do an "svn ls -v http://server/repo/path" on a repository with
26k locked files, the server generates an 11MB xml response
that included lock information and lock comments for the whole
repository.  Almost 100% of this information was discarded in the output
of the "svn ls -v" command.

It appears to be doing a recursive lock report, even though
the "svn ls" command is not requesting recursive behavior.

Is there an API limitation that makes all REPORT commands
for locks show recursive information?

This can make GUIs such as the TortoiseSVN repo-browser painfully
slow due to the large amount of data returned for every path that is 
navigated.

Any guidance on where I might start digging into this in
the source code?

Thanks!
Kevin R.

Re: lock report inefficiencies

["C. Michael Pilato" <cm...@collab.net>]

C. Michael Pilato wrote:
> It would seem that the RA layer -- which is already using custom protocol
> bits anyway -- could stand to support a 'depth' parameter on the get_locks()
> request.  Server-side, we could propagate that 'depth' parameter down into
> the FS layer, or simply implement the obvious workaround (iterations over
> svn_fs_get_lock()) when the depth is something other than "infinity".

Tracking this in issue #3661:
http://subversion.tigris.org/issues/show_bug.cgi?id=3661

I've got a patch running through N-way test suite right now.

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: lock report inefficiencies

["C. Michael Pilato" <cm...@collab.net>]

kmradke@rockwellcollins.com wrote:
> When debugging some repository performance problems, I narrowed it
> down to repositories with large numbers of locked files.  For example,
> if I do an "svn ls -v http://server/repo/path" on a repository with
> 26k locked files, the server generates an 11MB xml response
> that included lock information and lock comments for the whole
> repository.  Almost 100% of this information was discarded in the output
> of the "svn ls -v" command.
> 
> It appears to be doing a recursive lock report, even though
> the "svn ls" command is not requesting recursive behavior.
> 
> Is there an API limitation that makes all REPORT commands
> for locks show recursive information?
> 
> This can make GUIs such as the TortoiseSVN repo-browser painfully
> slow due to the large amount of data returned for every path that is 
> navigated.
> 
> Any guidance on where I might start digging into this in
> the source code?

Starting at the storage layer, you'll find the APIs svn_fs_get_locks() which
is all-the-locks-in-the-repository-at-or-under-some-path and
svn_fs_get_lock() which queries a single path, non-recursively.

Stepping upward through the layers, you find that the RA layer doesn't know
how to integrate lock information with primary information needed when
fielding an 'svn ls -v' request.  So the client API vn_client_list2() has to
first get the lock data via svn_ra_get_locks() (recursive!), then get the
'svn ls -v' data via svn_ra_get_dir(), and finally merge the two sets of
information together for presentation.

It would seem that the RA layer -- which is already using custom protocol
bits anyway -- could stand to support a 'depth' parameter on the get_locks()
request.  Server-side, we could propagate that 'depth' parameter down into
the FS layer, or simply implement the obvious workaround (iterations over
svn_fs_get_lock()) when the depth is something other than "infinity".

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand