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.
Usage of the "text_state" local variable in
libsvn_client/merge.c:do_single_file_merge(), where we explicitly
invoke notification_receiver(), seems interesting.
Note that work on this may overlap with Peter Lundblad's improvements
to the merge algorithm.
- application/pgp-signature attachment: stored
Received on Tue Mar 27 20:39:04 2007