subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Hett <>
Subject Re: inconsistency between mergeinfo records
Date Thu, 25 Jun 2015 12:40:24 GMT
Hi Stefan,
>         If you have a working build environment for Subversion,
>         you might have a look at this branch:
>         It provides a new tool that you might find useful:
>         ./tools/client-side/svn-mergeinfo-normalizer/svn-mergeinfo-normalizer
>         which allows you to analyse and reduce the mergeinfo in a
>         working copy.
>         It also tells you which mergeinfo cannot be elided and _why_.
>         svn-mergeinfo-normalizer analyse /path/to/working/copy
>         svn-mergeinfo-normalizer normalize /path/to/working/copy
>         svn-mergeinfo-normalizer analyse /path/to/working/copy
>         svn-mergeinfo-normalizer clear-obsoletes /path/to/working/copy
>         svn-mergeinfo-normalizer analyse /path/to/working/copy
>         svn-mergeinfo-normalizer combine-ranges /path/to/working/copy
>         svn-mergeinfo-normalizer analyse /path/to/working/copy
>         CAVEAT: This tool has not been reviewed and thoroughly tested.
>         You should only commit changes that you have verified to be
>         correct.
>         Please let us know what your results were.
>     [...]
>     I gave the normalizer a first run and using it I was able to
>     reduce our record of mergeinfos quite significantly without too
>     much manual work. So alltogether I'd consider this a really useful
>     tool.
>     I sent you the logs per PM so you can take a look at all the
>     details yourself (some of the information contained in the logs I
>     do not want to make publicly available on the mailing list and
>     it's quite some large logs (several MB)).
> Those logs are really helpful. I've already found a number of
> things that should be improved:
> * Branches should always be sorted by name
> * 'analyze' should also check whether obsolete branches can be elided.
>   The 'normalize' step already does this.
I already tested ur committed changes from yesterday and see that these 
changes have been added. Looks quite good and especially the sorted 
branches helps reviewing the analyse-output IMO.

> [...]
>     Note that running normalize at the beginning, could not remove any
>     redundant mergeinfos at all, since there were always some
>     revisions missing. However running the following sequence of
>     commands first:
>     1. clear-obsoletes
>     2. combine-ranges
>     3. normalize
>     Then was able to remove a significant amount of redundant
>     mergeinfos (eliminating mergeinfos on over 100 files).
> I guess that was due to 'clear-obsoletes' removing lots of old merges
> from old branches where sub-tree mergeinfo could indeed not be elided.
> Once the extended analyze output is available as described above,
> you should be able to verify that hypothesis. That said, removing
> obsolete branches first is certainly a very efficient workflow.
That's correct and I could confirm it with the new analyze output to 
actually having been the case here (also sent u the full output so u can 
confirm --- sample for such a case was this one in the logs:

(note that the same applies to basically all files/records in 
data/shaderfx/xxx so this applied to the majority of the cases)

> [...]
>     There were still some remaining records. These I managed to get
>     rid of by manually merging the missing ranges.
> There are also a few genuine sub-tree merges that look like a sync
> with some vendor branch. Some might be replaced by svn:externals -
> which comes with a few restrictions as well as benefits.
I'm aware of the possibility to use svn:externals for cases like these. 
The reason we ended-up with not using svn:externals in the cases shown 
in the logs is mostly historically.
I introduced SVN in our company when I started here around 2007/2008 
(migrating from MS VSS) at which time we started with SVN 1.5. As you 
most likely know way better than me, while the svn-externals 
concept/support evolved significantly over the past years (and I'd call 
it quite a stable and useful feature in the current versions), there 
were several issues/bugs/limitations regarding svn-externals in 1.5/1.6/1.7.
Since we had to invest a lot of work resolving some of these, we 
ended-up not using svn-externals in the cases here. Also like you state 
urself there are certain advantages here, which in our case overweight 
the disadvantages atm.


View raw message