[jira] [Created] (SVN-4669) Merge with much subtree mergeinfo takes hours

["Julian Foad (JIRA)" <ji...@apache.org>]

Julian Foad created SVN-4669:
--------------------------------

             Summary: Merge with much subtree mergeinfo takes hours
                 Key: SVN-4669
                 URL: https://issues.apache.org/jira/browse/SVN-4669
             Project: Subversion
          Issue Type: Bug
    Affects Versions: 1.9.5
            Reporter: Julian Foad


When there is explicit mergeinfo on thousands of subtrees, a merge at the subtree root can take several hours.

The merge code makes multiple (4 in my test) synchronous svn_ra_get_location_segments() queries to the server for each subtree with mergeinfo. If, for example, 3600 subtrees have mergeinfo and each query takes 0.25 second, that adds up to an hour.

This is related to but different from the memory usage issue SVN-4667. The results of most of these queries are stored temporarily and account for only 10% of the total memory used in my test.

Possible approaches to improving the merge code are: (1) make the queries much more efficient; and (2) analyse how the results are used and eliminate unnecessary queries.

The work-flow approach to improving the experience is: get the number of subtrees with mergeinfo down to none or very few.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Created] (SVN-4669) Merge with much subtree mergeinfo takes hours

[Daniel Shahaf <d....@daniel.shahaf.name>]

[CC += dev@; CC -= jira@]

Julian Foad (JIRA) wrote on Tue, Jan 17, 2017 at 16:06:26 +0000:
> The merge code makes multiple (4 in my test) synchronous
> svn_ra_get_location_segments() queries to the server for each subtree
> with mergeinfo. If, for example, 3600 subtrees have mergeinfo and each
> query takes 0.25 second, that adds up to an hour.
> 
> This is related to but different from the memory usage issue SVN-4667.
> The results of most of these queries are stored temporarily and
> account for only 10% of the total memory used in my test.
> 
> Possible approaches to improving the merge code are: (1) make the
> queries much more efficient; and (2) analyse how the results are used
> and eliminate unnecessary queries.

The change could be done in a few places:

1. libsvn_client could call svn_ra_get_location_segments() fewer times

2. The svn_ra_get_location_segments() calls could send fewer requests to
the server (e.g., by memoizing/caching results of earlier calls, to
make the later calls faster)

3. The server could be made to answer mergeinfo queries faster (whether
by methods similar to #2 or for that matter by inventing a new backend)

Cheers,

Daniel

> The work-flow approach to improving the experience is: get the number
> of subtrees with mergeinfo down to none or very few.