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

Re: Merging the subtree-mergeinfo branch back to trunk

From: Paul Burba <ptburba_at_gmail.com>
Date: Fri, 7 Aug 2009 09:21:35 -0400

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


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

Received on 2009-08-07 15:21:51 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.