[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Merging the subtree-mergeinfo branch back to trunk

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 4 Aug 2009 16:54:08 -0400

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
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:'

  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.

    svn:mergeinfo on 1,300 files when only a few changed?

    After a merge some files are (erroneously?)shown as modifed

    Useless explicit mergeinfo records:

    Proposal: don't modify any unrelated mergeinfos during 'svn merge':

    General user frustrations:

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
 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.


Received on 2009-08-04 22:54:30 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.