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 15:21:51 CEST