kmradke_at_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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-04-14 20:08:53 CEST