You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Rall <dl...@collab.net> on 2007/01/17 00:28:32 UTC
[merge tracking] Merge test #12: No-op merging of the svn:mergeinfo property
Merge test #12 was marked as XFAIL in r22119. I'd like some feedback
on what y'all think the expected behavior should be. Stripping out
the irrelevant stuff, here's the situation:
$ svn cp TRUNK_URL BRANCH_URL # create r2
$ # Do some other unrelated stuff to create r3
$ svn pg svn:mergeinfo BRANCH_URL@2
/A:1
$ svn pg svn:mergeinfo TRUNK_URL@3
$ svn di BRANCH_URL@2 TRUNK_URL@3
Property changes on: .
___________________________________________________________________
Name: svn:mergeinfo
- /A:1
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?
Re: [merge tracking] Merge test #12: No-op merging of the svn:mergeinfo property
Posted by Daniel Rall <dl...@collab.net>.
Ping. Anyone have a take on this? If not, I'm likely to go with the
property merge notification we're currently getting on the
merge-tracking branch.
On Tue, 16 Jan 2007, Daniel Rall wrote:
> Merge test #12 was marked as XFAIL in r22119. I'd like some feedback
> on what y'all think the expected behavior should be. Stripping out
> the irrelevant stuff, here's the situation:
>
> $ svn cp TRUNK_URL BRANCH_URL # create r2
> $ # Do some other unrelated stuff to create r3
> $ svn pg svn:mergeinfo BRANCH_URL@2
> /A:1
> $ svn pg svn:mergeinfo TRUNK_URL@3
> $ svn di BRANCH_URL@2 TRUNK_URL@3
>
> Property changes on: .
> ___________________________________________________________________
> Name: svn:mergeinfo
> - /A:1
>
> 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?
Re: [merge tracking] Merge test #12: No-op merging of the svn:mergeinfo property
Posted by Daniel Rall <dl...@collab.net>.
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.
Re: [merge tracking] Merge test #12: No-op merging of the svn:mergeinfo property
Posted by Malcolm Rowe <ma...@farside.org.uk>.
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.
Regards,
Malcolm