On Sun, Aug 16, 2015 at 12:30 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
wrote:
> Stefan Fuhrmann wrote on Sat, Aug 15, 2015 at 20:18:53 +0100:
> > Although we technically could, we will neither merge from
> > them (using the branch_at_rev notation) nor resurrect them
> > in the future. Therefore, I'd like to shave off 15k from our
> > mergeinfo by removing those unused entries. List below.
>
> 15KB of space saving doesn't sound like a noticeable benefit.
>
The "15k" part was just fyi - in case people wanted to
know how big the savings would be.
> > Is there a compelling reason not to do it?
>
> Dogfooding: we shouldn't make changes to our mergeinfo that users cannot
> make too. Would users be able to make such changes to their own
> repositories? (without being with the internals of mergeinfo
> implementation)
>
Yes, using the same command that I planned on using:
svn-mergeinfo-normalizer remove-branches -F $FileWithListOfBranches
If people feel adventurous, they might even do it automatically:
svn-mergeinfo-normalizer normalize --remove-obsoletes
The whole point of that tool is to help large projects to reduce their
mergeinfo from hundreds of MB to something manageable again.
Enhanced sub-tree mergeinfo elision logic will help them somewhat.
But at >100k mergeinfo per node, eliminating the records of mistaken
merges and simply long-forgotten branches is an important feature,
too. Note that those users run out of memory today during merges
because the total amount of merginfo in memory is > 1GB.
The downside of removing branches from m/i is that they appear
as an "unmerge" in the log. Very few people should actually care
but there might be unintended side-effects. As the Subversion
project and with our straightforward branching scheme, we should
be in the best possible position to fix / deal with those side-effects
if they should occur. So, this would be dogfooding for us.
-- Stefan^2.
Received on 2015-08-18 17:03:22 CEST