Paul Burba wrote:
> A) MERGE TO A SWITCHED PATH:
> 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.
Makes sense to me.
> B) MERGE TO A PATH WITH SWITCHED CHILD:
> 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.
[Bear with me -- I'm having trouble convincing myself that my words make sense.]
You've not listed this explicitly, but in "Current behavior", is it not also
the case that PATH gets mergeinfo for rX? I think that's the correct
behavior, too. But it does leave room for a gotcha.
If I have PATH and PATH_C, where PATH_C is switched elsewhere, the I think
you're saying that after a merge of URL onto PATH, both PATH and PATH_C
should have explicit mergeinfo recorded for the merge.
But what about the repository location that PATH_C is overriding? If I
checkout a new tree of PATH, I'll get PATH_C as well -- but it isn't the
same PATH_C as was in the switched working copy. My unswitched PATH_C
inherits mergeinfo from its parent, which has such recorded for rX. But my
unswitched PATH_C doesn't *have* the merged data from rX.
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Apr 18 20:23:25 2007