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

[RFC] Merge Tracking: svn:mergeinfo and svn switch

From: Paul Burba <pburba_at_collab.net>
Date: 2007-04-17 17:04:10 CEST

> -----Original Message-----
> From: Peter Lundblad [mailto:plundblad@google.com]
> Sent: Wednesday, March 14, 2007 6:11 PM
> To: Daniel Rall
> Cc: dev@subversion.tigris.org; Daniel Berlin
> Subject: Re: [merge tracking] Prop changes to the
> "svn:mergeinfo" property
> On a side note, are we going to support the case where we
> update merge info (as the result of a merge) but a child path
> is switched?

Dan and I were discussing this yesterday in IRC:

<pburba> dlr_h: What would we consider the "right thing" when the target
of a merge has a switched child. If the switched child has its own
mergeinfo it stays untouched? And if it has none it gets an empty set
of mergeinfo?
<dlr_h> While it may not be consistent with what I've said in the past,
I now tend to think that we should be mucking with the merge info of a
switched child path.
<dlr_h> For instance, what if I switched part of my WC to a branch, but
also had part on trunk.
<dlr_h> If I do a merge which effects both portions, both should have
applicable merge info recorded.
<dlr_h> 'switch' would need to be more intelligent about updating merge
info, especially since it may have to account for differences in
inherited merge info between original parent, and the parent subsequent
to the 'switch' operation
<dlr_h> pburba: What do you think?
<pburba> dlr_h: I need to think about this a bit, I'm not sure what
makes the most sense
<dlr_h> okay
<dlr_h> pburba: Would you follow up to that email with our thoughts (and
a better Subject line)?
<pburba> sure thing
<dlr_h> Thanks! We should vet this on-list.
<pburba> I need to play with some concrete examples, I'm not getting
anywhere thinking about it in a completely abstract manner

So I thought a bit (well a lot actually) on switch and merge tracking
and see three cases where the current behavior is broken and we need to
agree on the appropriate behavior:


PATH's working copy parent PATH_P has explicit mergeinfo for rev Y.
PATH is then switched to URL2. svn merge -cX URL1 PATH.

Current behavior: PATH gets mergeinfo set for rX,Y.

Correct behavior: PATH gets mergeinfo set *only* for rX as a local
modification. PATH shouldn't inherit mergeinfo from PATH_P, the
inheritance code needs to stop climbing the WC looking for inherited
mergeinfo when it hits a switched path.

svn merge -cX URL PATH where PATH has a switched child PATH_C with no
explicit mergeinfo.

Current behavior: PATH_C has no mergeinfo recorded. PATH_C has rX
merged into it, though this information is never getting into the repos.
If this merge is committed and another user checks out URL and tries to
merge in rX, a repeat merge is allowed.

Correct behavior: PATH_C has mergeinfo added for rev X as a local

Note: If PATH_C has explicit mergeinfo prior to the merge then
everything is ok, PATH_C gets mergeinfo for rX.

svn sw URL PATH where PATH's parent PATH_P has identical mergeinfo to
that added to PATH from URL/PATH.
Current (patch) behavior: PATH's mergeinfo elides to PATH_C. Again this
sets up the potential for a repeat merge.

Correct behavior: Never elide the target of a switch (the switch target
is effectively the root of the WC in terms of elision). The only
exception is when the switch is reversing an earlier switch and leaving
PATH in an unswitched state.

If A and B are implemented, I don't see any problems with switch itself
(other than elision):

D) svn switch URL PATH

Current behavior: PATH's mergeinfo is replaced by the mergeinfo from URL
(if any) regardless of whether PATH had explicit mergeinfo prior to the
switch or not.
E) svn switch URL PATH where PATH has a child PATH_C with explicit
mergeinfo prior to the switch

Current behavior: PATH_C's mergeinfo is replaced by the mergeinfo from
URL/PATH_C (if any).

Agree, disagree with the above? Any other cases involving switch and
mergeinfo I've not considered where you see problems?

Paul B.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 17 17:04:52 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.