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