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
Received on 2015-06-25 14:40:56 CEST