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

Re: Merging the subtree-mergeinfo branch back to trunk

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 7 Aug 2009 10:17:29 -0400

On Fri, Aug 7, 2009 at 9:53 AM, Greg Stein<gstein_at_gmail.com> wrote:
> Hmm. I seem to recall asking about this branch, and the reply was
> along the lines of "we're doing some investigation and running
> experiments" or somesuch. IOW, no need to review the changes on the
> branch.
> And now... it is going to be merged. That's a pretty dramatic departure.

Hi Greg,

I don't recall what I said exactly, but as I said at the start of this
thread my primary reasons for having it on a branch were:

1) I suspected the basic change the branch implements, not recording
mergeinfo on subtrees unaffected by the merge, would cause a serious
performance regression in certain use cases. I wanted to be sure that
if such a regression existed and that it could be addressed. There
was such a regression and it has been fixed on the branch.

2) The behavior change would cause a number of merge tests to fail,
and I didn't want to go through the tedious work of fixing them until
I was sure I could address #1.

IMO it seemed like a branch was the way to go. All my* concerns have
been addressed, it passes the test suite (more accurately it fails
where trunk fails), and I think it is ready for trunk.

* Obviously if others have concerns I want to hear them!

> Has there been anybody reviewing the changes going into this branch?

I don't believe anyone has been monitoring the branch on an ongoing
basis no. That is why I posted this message a few days back and
haven't been in any hurry to merge it back.


> Cheers,
> -g
> On Fri, Aug 7, 2009 at 15:21, Paul Burba<ptburba_at_gmail.com> wrote:
>> Hi All,
>> Just an fyi: I'm going to make a final sync with trunk, run the tests,
>> and, barring anything unexpected, will merge this branch back to trunk
>> today.
>> Paul
>> On Tue, Aug 4, 2009 at 4:54 PM, Paul Burba<ptburba_at_gmail.com> wrote:
>>> Back in March I created the subtree-mergeinfo branch to explore the
>>> ramifications of not setting mergeinfo on subtrees unaffected by a
>>> merge.  Currently if you perform a merge tracking aware merge of URL
>>> -rM:N to WC_TARGET, then every path under WC_TARGET with explicit
>>> mergeinfo has that mergeinfo updated to reflect the merge of URL
>>> -rM:N, regardless of whether the subtree or any of its children were
>>> affected by the merge.
>>> If you are not already nodding your head regarding the implications of
>>> this, then this excerpt from
>>> http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/notes/subtree-mergeinfo/overview.txt
>>> sums it up:
>>>  There was a short time pre-1.5.0 when no-op merges didn't
>>>  update any mergeinfo, but we eventually decided to always
>>>  set mergeinfo as discussed here: 'RFC: Allow no-op merges
>>>  to modify mergeinfo:'
>>>  http://svn.haxx.se/dev/archive-2008-03/0914.shtml.
>>>  Note: This branch is *not* about whether to record mergeinfo
>>>  *at all* for no-op merges, I still plan for no-op merges to
>>>  record mergeinfo on the merge target.  Rather this is about
>>>  whether to modify subtree mergeinfo when the subtree is
>>>  unaffected by the merge.
>>>  Presently this branch also attempts to elide subtree
>>>  mergeinfo for all subtrees with mergeinfo, regardless of
>>>  whether the subtree is touched by the merge (see r38455).
>>>  This is one time it makes sense to modify subtree mergeinfo
>>>  when that subtree is unaffected by the merge, since it is
>>>  *reducing* the amount of subtree mergefino which I suspect
>>>  everyone will agree is a good thing...and if not it's easy
>>>  to flip the behavior.
>>>  Recording mergeinfo on subtrees unaffected by the merge has
>>>  not, to put it charitably, proven very popular or been very well
>>>  understood.  The major complaints are of the "I just merged
>>>  rN from trunk which changes one file on trunk, but my branch
>>>  WC has hundreds of local mods (mergeinfo)!."  Even where users
>>>  understand what is going on there is the complaint that the
>>>  "signal" of merged changes gets lost in the "noise" of subtree
>>>  mergeinfo prop changes.  The following is just a sample of the
>>>  complaints (simply search the users list for 'mergeinfo' and
>>>  you'll find no shortage of similar complaints):
>>>    Merge tracking implementation issue.
>>>    http://svn.haxx.se/users/archive-2009-04/0459.shtml
>>>    svn:mergeinfo on 1,300 files when only a few changed?
>>>    http://svn.haxx.se/users/archive-2009-04/0437.shtml
>>>    After a merge some files are (erroneously?)shown as modifed
>>>    http://subversion.tigris.org/ds/viewMessage.do?dsForumId=
>>>    1065&dsMessageId=1219898
>>>    Useless explicit mergeinfo records:
>>>    http://svn.haxx.se/dev/archive-2008-08/0793.shtml
>>>    Proposal: don't modify any unrelated mergeinfos during 'svn merge':
>>>    http://svn.haxx.se/dev/archive-2008-09/0443.shtml
>>>    General user frustrations:
>>>    http://svn.haxx.se/users/archive-2009-06/0372.shtml
>>> This work was done on a branch because it was an open question whether
>>> the change result in serious performance regressions and whether such
>>> regressions could be fixed, not to mention the general havoc it would
>>> wreak with the merge tests.
>>> Turns out the the performance problem was serious, see the
>>> 'Inoperative Editor Drive Problem' in
>>> http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/notes/subtree-mergeinfo/the-performance-problem.txt.
>>>  But fixing it was straightforward, see r38504.  Note that the other
>>> problem described in 'the-performance-problem.txt', the 'Implicit
>>> Mergeinfo Query Problem', was not unique to the work being done on the
>>> branch and was fixed on trunk (see issue #3443).
>>> There are still some problems that this branch introduces, specifically:
>>> 1) Elision, in it's current form, will be mostly useless, see '2)
>>> ELISION.' in http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/notes/subtree-mergeinfo/overview.txt.
>>> 2) I'm not entirely convinced reintegrate can't be broken by doing
>>> some series of root and subtree merges that is equivalent to regular
>>> sync merges.  The reintegrate tests pass and I haven't been able to
>>> cause a problem in my ad hoc testing...maybe I just can't believe it
>>> still works correctly :-)
>>> Regardless, I believe this branch is now ready to be merged back to
>>> trunk.  The 'Inoperative Editor Drive Problem' is addressed, the test
>>> suite is adjusted to expect the new behavior and all tests pass, and
>>> the two aforementioned problems can be dealt with on trunk.
>>> If anyone has objections and/or questions please let me know.
>>> Paul
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2381296

Received on 2009-08-07 16:17:49 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.