On Thu, 25 Jan 2007, Malcolm Rowe wrote:
> On Tue, Jan 16, 2007 at 04:28:32PM -0800, Daniel Rall wrote:
> > So, BRANCH_URL has some merge info, and trunk doesn't.
> >
> > $ svn merge BRANCH_URL@2 TRUNK_URL@3 WC_PATH
> > G svn-test-work/working_copies/merge_tests-12/A
> >
> > A merge of the difference between these two URLs produces a delta,
> > which is a revert of some merge info which doesn't exist on TRUNK_URL,
> > nor happens to exist in WC_PATH (which happens to correspond to
> > TRUNK_URL). So, even though we have a delta, application of the delta
> > is a no-op.
> >
> > Should we still send a mer' G'ed notification?
>
> Yes, I don't see a problem with that. It's a little odd that the merge
> to an unmodified property in a wc can result in a property that's still
> unmodified, but that's a result of the intelligent merging carried out
> for that property, and I don't think it's much odder than the fact that
> a merge (typically from 'svn up') can result in file contents going from
> modified to unmodified (because an in-wc patch was applied to the repo
> via another wc).
>
> The way I see it, the notification is that we merged a change to that
> property - it doesn't guarantee that the property will have changed
> state after the fact.
Thanks Malcolm. I went ahead and fixed the test along these lines today.
- application/pgp-signature attachment: stored
Received on Mon Jan 29 19:04:30 2007