kmra...@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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
