Re: Mergeinfo still not eliding in Subversion 1.6.5

On Tue, Sep 29, 2009 at 6:19 PM, Bob Archer <bob.archer_at_amsi.com> wrote:

> Perhaps Mark or Hyrum can confirm or deny my assumptions here.

First there is a misunderstanding of elision. This feature has worked
properly since 1.5.0 and has not really needed any changes since.

Elision is the process of recognizing that a subtree's mergeinfo does
not differ from a parent's mergeinfo and so it is removed or elided to
the parent. Consider this scenario:

* You merge r100 and 101 to a subtree creating mergeinfo different
from the parent
* Now you merge r200 to the parent. The Subtree mergeinfo is not
elided but updated to include r200. It cannot be elided because the
parent does not have r100 or 101.
* Now you merge r100 to the parent. The subtree mergeinfo is
unchanged because it already has r100. It cannot be elided because
the parent does not have r101.
* Now you merge r101 to the parent. The subtree mergeinfo is elided
away because it no longer is different than the parent.

This is also one of the reasons that subtree mergeinfo is updated when
you merged r200 to the parent. If you did not do this, then you could
not later elide away the mergeinfo on the subtree when the parent
receives r100 and 101. Because the subtree would be different in that
it does not know it has r200. Had we stored the subtree mergeinfo
using a custom format that only expressed the differences, we would
not have this problem. But that ship has sailed.

Subversion 1.7 has a behavior change here. We will no longer update
the subtree's that are not effected by a merge. This means that
elision would never happen in the scenario above. We have decided
this is a change worth making because the scenario described above
never seems to happen in reality. There was another reason that
subtrees were updated though, and that is for performance. If the
subtree is not updated then every merge has to constantly check again
for revisions ranges that do not impact the subtree. Eventually this
causes massive performance problems. Changes were made in 1.7 to
prevent this from happening.

Finally, there have been a lot of performance improvements to merge
since 1.5.2. There is a big improvement when there are a lot of
subtrees involved, but it is still only nominated for backport to
1.6.x and does not have the code review votes needed be included. So
that will come in 1.7.

My best advice would be to just remove all your subtree mergeinfo and
be careful to do all merges from your project root going forward so
that you do not accumulate more mergeinfo. And also update all
clients to 1.5.7 or 1.6.5 so that spurious subtree mergeinfo is not
created via the copy/move commands. This was the main source of the
subtree mergeinfo accumulation in most repositories.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2401813
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].