Re: inconsistency between mergeinfo records

Hi Stefan^2,

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

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

There were still some remaining records. These I managed to get rid of
by manually merging the missing ranges.

One remaining case which couldn't be normalized automatically was on
"/src/version_generator".
Revision 190854 was recorded on root and on src but not on
src/version_generator.
190854 was actually the creation of a branch (XRebirth/branches/XR_ogl).
So I guess (in theory) the normalizer could have handled that missing
range as an irrelevant revision for eliding the remaining branches.
Wouldn't it be possible/useful to handle that by the tool automatically?

Regarding your other questions I'll get back to you later.

Regards,
Stefan