Re: Possible Merge Tracking TODO: No notification of merges on children with mergeinfo unaffected by the merge

On Tue, 27 Mar 2007, Daniel Rall wrote:

> On Tue, 27 Mar 2007, Paul Burba wrote:
>
> > The current notification behavior when merging into a target with child
> > file paths that contain their own merge info seems a bit off when those
> > children are unaffected by the merge:
> >
> > An example will probably make what I'm trying to say clearer:
> >
> > Starting with a standard test suite greek tree:
> >
> >
> > 1) Make a branch and commit it
> > ------------------------------
> > >set
> > URL=file:///C:/SVN/src-trunk/Release/subversion/tests/cmdline/svn-test-w
> > ork/repositories/merge_tests-1
> >
> > >svn copy %URL%/A/D merge_tests-1/A/D_COPY
> > A merge_tests-1\A\D_COPY\gamma
> > A merge_tests-1\A\D_COPY\G
> > A merge_tests-1\A\D_COPY\G\pi
> > A merge_tests-1\A\D_COPY\G\rho
> > A merge_tests-1\A\D_COPY\G\tau
> > A merge_tests-1\A\D_COPY\H
> > A merge_tests-1\A\D_COPY\H\chi
> > A merge_tests-1\A\D_COPY\H\omega
> > A merge_tests-1\A\D_COPY\H\psi
> > Checked out revision 1.
> > A merge_tests-1\A\D_COPY
> >
> > >svn ci -m "" merge_tests-1
> > Adding merge_tests-1\A\D_COPY
> >
> > Committed revision 2.
> >
> >
> > 2) Make two mods to the source of the branch
> > --------------------------------------------
> > >echo new content > merge_tests-1\A\D\H\chi
> >
> > >svn ci -m "" merge_tests-1
> > Sending merge_tests-1\A\D\H\chi
> > Transmitting file data .
> > Committed revision 3.
> >
> > >echo new content > merge_tests-1\A\D\G\rho
> >
> > >svn ci -m "" merge_tests-1
> > Sending merge_tests-1\A\D\G\rho
> > Transmitting file data .
> > Committed revision 4.
> >
> >
> > 4) Merge one of the mods into a branch
> > target unaffected by the merge. Note
> > that there are no notifications, but the
> > mergeinfo on the target is appropriately
> > updated.
> > ------------------------------------------
> > >svn merge %URL%/A/D/G merge_tests-1\A\D_COPY\G -c3
> >
> > >svn pl -vR merge_tests-1
> > Properties on 'merge_tests-1\A\D_COPY':
> > svn:mergeinfo : /A/D:1
> > Properties on 'merge_tests-1\A\D_COPY\G':
> > svn:mergeinfo : /A/D/G:1,3
> >
> >
> > 5) Revert the previous merge
> > ----------------------------
> > >svn revert -R merge_tests-1
> > Reverted 'merge_tests-1\A\D_COPY\G'
> >
> >
> > 6) Now merge the other mod into the same
> > target, one of the target's children is
> > affected this time and we get an
> > appropriate notification and mergeinfo.
> > ------------------------------------------
> > >svn merge %URL%/A/D/G/rho merge_tests-1\A\D_COPY\G\rho -c4
> > U merge_tests-1\A\D_COPY\G\rho
> >
> > >svn pl -vR merge_tests-1
> > Properties on 'merge_tests-1\A\D_COPY':
> > svn:mergeinfo : /A/D:1
> > Properties on 'merge_tests-1\A\D_COPY\G\rho':
> > svn:mergeinfo : /A/D/G/rho:1,4
> >
> >
> > 7) Now repeat the first merge we performed,
> > the mergeinfo is set correctly, but we get
> > a notification that rho is mer'G'ed which
> > isn't true since r3 doesn't affect rho.
> > ------------------------------------------
> > >svn merge %URL%/A/D/G merge_tests-1\A\D_COPY\G -c3
> > G merge_tests-1\A\D_COPY\G\rho
> >
> > >svn pl -vR merge_tests-1
> > Properties on 'merge_tests-1\A\D_COPY':
> > svn:mergeinfo : /A/D:1
> > Properties on 'merge_tests-1\A\D_COPY\G':
> > svn:mergeinfo : /A/D/G:1,3
> > Properties on 'merge_tests-1\A\D_COPY\G\rho':
> > svn:mergeinfo : /A/D/G/rho:1,3-4
> >
> > Note: If the target child is a directory the 'G' notification doesn't
> > occur.
> >
> > So, should the notification in 7) not occur? If so I'll add this to the
> > "Handle notifications resulting from a merge." section in
> > http://svn.collab.net/repos/svn/trunk/notes/merge-tracking.txt and/or
> > look into a fix.
>
> Paul, the notification from step #7 shouldn't occur. I'd hazard a
> guess that the notification is related to the way handling for
> sub-tree merge info performs a separate editor drive for children of
> the target of a merge which have their own merge info, likely in
> conjunction with the fact that this is a single file.

From reading the code, this seems to be it.

> Usage of the "text_state" local variable in
> libsvn_client/merge.c:do_single_file_merge(), where we explicitly
> invoke notification_receiver(), seems interesting.
...

do_single_file_merge() calls merge_file_changed(), which sets
text_state. merge_file_changed() in turn calls svn_wc_text_modified_p()
to detect whether the target WC path has any local mods. The local
mods from the merge in step #6 are detected, and the notification is
set accordingly:

          else if (has_local_mods)
            *content_state = svn_wc_notify_state_merged;

Since no merge actually occurs to "rho" during step #7, I still think
we need a way to silence this notification for this particular case.
If everyone agrees with this, we can special-case the way
discover_and_merge_children() calls do_single_file_merge() (e.g. drill
another flag into do_single_file_merge() for whether or not to send
notifications for this case).