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

Re: [merge tracking] Merge test #12: No-op merging of the svn:mergeinfo property

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-01-27 02:28:05 CET

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

This is an archived mail posted to the Subversion Dev mailing list.