> -----Original Message-----
> From: Mark Phippard [mailto:markphip_at_gmail.com]
> Sent: Tuesday, September 29, 2009 5:10 PM
> To: Bob Archer
> Cc: Gleason, Todd; users_at_subversion.tigris.org
> Subject: 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.
Thank you--that's the clearest I've seen things explained. While I
think I understand what you've said, you won't be surprised that I don't
like how it works in 1.5.x-1.6.x, and am glad for what 1.7 will change.
It seems like in 1.7 we'll see all this:
* No updating of subtree mergeinfo, removing the urge to delete subtree
mergeinfo
* Much higher performance when merging from the WC root (due to wc-ng
and the subtree optimization you mentioned above), removing the urge to
merge at the subtree level and create more subtree mergeinfo
With all that, it sounds like the fact that Subversion doesn't identify
that a subtree merge actually merged all the changes from a given
revision, and elide it to a parent path, should become more or less
irrelevant. Now I'm even more eager for 1.7 than I was before. Can you
tell me how much of the performance improvement and subtree mergeinfo
changes are client-side, and how much are server-side? In particular,
if we upgrade the server to 1.6.5 now, will we have to upgrade it again
to 1.7.x to get the desired behavior and better performance?
--Todd
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2402307
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-01 00:06:56 CEST