[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: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-01-25 12:58:38 CET

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.


  • application/pgp-signature attachment: stored
Received on Thu Jan 25 13:19:05 2007

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