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.
Paul
> 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
>>
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2381317
Received on 2009-08-07 16:17:49 CEST