'svn log -g' performance degradation with large changesets

(See also the message at http://svn.haxx.se/dev/archive-2010-04/0499.shtml.)

When getting the history for a path including merge info (svn log -g) and the history involves a revision with many changed paths the command takes a long time to complete (around a minute compared to seconds it takes when no such revision is involved).

To reproduce this take a repository with > 10,000 files and check the time it takes to get the history for a particular file (svn log -g). Then change SVN properties for all files and commit. Note that getting the history now takes much longer. In order to rule out any influence of a server (e.g. Apache) you should use the file: protocol for direct disk access.

First analysis by C. Michael Pilato suggests that examining revisions for merge info might be unnecessarily exhaustive.

Original issue reported by thbecker