[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: lock report inefficiencies

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 14 Apr 2010 14:08:24 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.