subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Zhakov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SVN-3639) 'svn log -g' performance degradation with large changesets
Date Sat, 17 Oct 2015 18:16:05 GMT

     [ 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)

Mime
View raw message