Hi Stefan,
If you have a working build environment for Subversion,
you might have a look at this branch:
https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-normalizer
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:
XR/clean_source_branch/data/shaderfx/medium/XU_effects_layered_unlit2_new.fx
(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.
Regards,
Stefan
