[
https://issues.apache.org/jira/browse/SVN-3639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Zhakov updated SVN-3639:
-----------------------------
Description:
(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*
was:
{noformat:nopanel=true}
(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.
{noformat}
Original issue reported by *thbecker*
> 'svn log -g' performance degradation with large changesets
> ----------------------------------------------------------
>
> Key: SVN-3639
> URL: https://issues.apache.org/jira/browse/SVN-3639
> Project: Subversion
> Issue Type: Improvement
> Components: libsvn_fs
> Affects Versions: 1.6.x
> Reporter: Subversion Importer
> Fix For: unscheduled
>
>
> (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*
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
