[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Removing deleted branches from our mergeinfo

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 18 Aug 2015 16:02:54 +0100

On Sun, Aug 16, 2015 at 12:30 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name>

> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.