Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <20150815233006.GF1952@tarsus.local2>
References: 
 <CA+t0gk140w=muDO0ZtY1odsAT8tjfCkmqnjnmfe4Z8o1QnSOGg@mail.gmail.com>
	<20150815233006.GF1952@tarsus.local2>
Date: Tue, 18 Aug 2015 16:02:54 +0100
Message-ID: 
 <CA+t0gk05Qu=toHxc1xm=xdmD+MH7ZZMPYqxXzqFV039jF8ZLng@mail.gmail.com>
Subject: Re: Removing deleted branches from our mergeinfo
From: Stefan Fuhrmann <stefan.fuhrmann@wandisco.com>
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: Subversion Development <dev@subversion.apache.org>
Content-Type: multipart/alternative; boundary=047d7b343b167d2838051d9736a8

--047d7b343b167d2838051d9736a8
Content-Type: text/plain; charset=UTF-8

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.

--047d7b343b167d2838051d9736a8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Aug 16, 2015 at 12:30 AM, Daniel Shahaf <span dir=
=3D"ltr">&lt;<a href=3D"mailto:d.s@daniel.shahaf.name" target=3D"_blank">d.=
s@daniel.shahaf.name</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">St=
efan Fuhrmann wrote on Sat, Aug 15, 2015 at 20:18:53 +0100:<br>
&gt; Although we technically could, we will neither merge from<br>
&gt; them (using the branch@rev notation) nor resurrect them<br>
&gt; in the future. Therefore, I&#39;d like to shave off 15k from our<br>
&gt; mergeinfo by removing those unused entries. List below.<br>
<br>
</span>15KB of space saving doesn&#39;t sound like a noticeable benefit.<br=
></blockquote><div><br></div><div>The &quot;15k&quot; part was just fyi - i=
n case people wanted to<br></div><div>know how big the savings would be. <b=
r></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"">&gt; Is there a compelling reason not to do it?<br>
<br>
</span>Dogfooding: we shouldn&#39;t make changes to our mergeinfo that user=
s cannot<br>
make too.=C2=A0 Would users be able to make such changes to their own<br>
repositories?=C2=A0 (without being with the internals of mergeinfo<br>
implementation)<br></blockquote><div><br></div><div>Yes, using the same com=
mand that I planned on using:<br><br></div><div>=C2=A0=C2=A0=C2=A0 svn-merg=
einfo-normalizer remove-branches -F $FileWithListOfBranches<br><br></div><d=
iv>If people feel adventurous, they might even do it automatically:<br></di=
v><div><br>=C2=A0=C2=A0=C2=A0 svn-mergeinfo-normalizer normalize --remove-o=
bsoletes<br><br></div><div>The whole point of that tool is to help large pr=
ojects to reduce their<br>mergeinfo from hundreds of MB to something manage=
able again.<br></div><div>Enhanced sub-tree mergeinfo elision logic will he=
lp them somewhat.<br></div><div>But at &gt;100k mergeinfo per node, elimina=
ting the records of mistaken<br></div><div>merges and simply long-forgotten=
 branches is an important feature,<br></div><div>too. Note that those users=
 run out of memory today during merges<br>because the total amount of mergi=
nfo in memory is &gt; 1GB.<br></div><div><br></div></div>The downside of re=
moving branches from m/i is that they appear<br></div><div class=3D"gmail_e=
xtra">as an &quot;unmerge&quot; in the log. Very few people should actually=
 care<br></div><div class=3D"gmail_extra">but there might be unintended sid=
e-effects. As the Subversion<br></div><div class=3D"gmail_extra">project an=
d with our straightforward branching scheme, we should<br></div><div class=
=3D"gmail_extra">be in the best possible position to fix / deal with those =
side-effects<br></div><div class=3D"gmail_extra">if they should occur. So, =
this would be dogfooding for us.<br><br></div><div class=3D"gmail_extra">--=
 Stefan^2.<br></div></div>

--047d7b343b167d2838051d9736a8--