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=2380164
Received on 2009-08-04 22:54:30 CEST