> -----Original Message-----
> From: Paul Burba [mailto:pburba@collab.net]
> Sent: Wednesday, March 28, 2007 12:45 PM
> To: Daniel Rall
> Cc: Subversion Development; Kamesh Jayachandran; Peter N. Lundblad
> Subject: RE: Possible Merge Tracking TODO: No notification of
> merges on children with mergeinfo unaffected by the merge
>
> > -----Original Message-----
> > From: Daniel Rall [mailto:dlr@collab.net]
> > Sent: Tuesday, March 27, 2007 2:55 PM
> > To: Paul Burba
> > Cc: Subversion Development; Kamesh Jayachandran; Peter N. Lundblad
> > Subject: 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:
>
> <snip>
>
> > > > 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;
>
> Looking at merge_file_changed() I wonder about Philip's old (from
> r12025) comment at the end of the callback:
>
> /* Philip asks "Why?" Why does the notification depend
> on whether the
> file had modifications before the merge? If the
> merge didn't change
> the file because the local mods already included the
> change why does
> that result it "merged" notification? That's
> information available
> through the status command, while the fact that the
> merge didn't
> change the file is lost :-( */
>
> if (content_state)
> {
> if (merge_outcome == svn_wc_merge_conflict)
> *content_state = svn_wc_notify_state_conflicted;
> else if (has_local_mods)
> *content_state = svn_wc_notify_state_merged;
> else if (merge_outcome == svn_wc_merge_merged)
> *content_state = svn_wc_notify_state_changed;
> else if (merge_outcome == svn_wc_merge_no_merge)
> *content_state = svn_wc_notify_state_missing;
> else /* merge_outcome == svn_wc_merge_unchanged */
> *content_state = svn_wc_notify_state_unchanged;
> }
>
> Any ideas on why we do this? I couldn't see why except the obvious:
> that we want to report paths as merged even if the local
> changes and the merge diff are identical. With
> merge-tracking there seems even less reason to do this since
> the svn:mergeinfo on 'rho' shows that r3 was merged into it.
>
> Simply changing...
>
> - else if (has_local_mods)
> + else if (has_local_mods
> + && merge_outcome != svn_wc_merge_unchanged)
>
> ...would solve the problem (though it results in a spurious failure in
> merge_test-1 and maybe elsewhere, I haven't checked the other
> tests yet).
A quick update:
Merge_test-42 obey_reporter_api_semantics_while_doing_subtree_merges
also fails, somehow I missed this the first time around. This is as
expected because the above "patch" doesn't report the numerous
'svn_wc_merge_unchanged' merges performed in the final merge of that
test.
All other tests pass over ra_local.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 29 14:32:47 2007