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.
Has there been anybody reviewing the changes going into this branch?
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=2381307
Received on 2009-08-07 15:53:52 CEST