subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: Removing deleted branches from our mergeinfo
Date Tue, 18 Aug 2015 15:02:54 GMT
On Sun, Aug 16, 2015 at 12:30 AM, Daniel Shahaf <d.s@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@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.

Mime
View raw message