Right now our mergeinfo inheritance and elision code doesn't account for
mixed rev working copies. In common practice this doesn't appear to be
much of a problem. Here "common practice" is taken to mean merging into
the root of a branch only where the branch doesn't have any subtrees
with explicit mergeinfo.
When merging to a branch root with subtrees with explicit mergeinfo or
performing merges directly to subtrees of a branch, things still work in
most common use cases, but we can produce incorrect elision/inheritance.
Take a simple example:
We have this WC:
/trunk
/trunk/a
/trunk/a/b
/trunk/a/c
Copy '/trunk' to '/branch' at r2.
Make a change to '/trunk/a/b' in r3.
Make a change to '/trunk/a/c' and '/trunk/a/b' in r4.
Merge r3 from '/trunk' to '/branch' and commit it as r5, creating
svn:mergeinfo '/trunk:3' on '/branch'.
Merge r4 from '/trunk' to '/branch' and commit it as r6, creating
svn:mergeinfo '/trunk:3-4' on '/branch'.
Now we update '/branch/a/c' to r5. This removes the change to
'/branch/a/b' the first merge made, but '/branch/a/b' still inherits
'/trunk/a/b:3-4' from '/branch' which is clearly wrong since only the
change from r3. '/branch/a/b' should have explicit or inherited
mergeinfo equivalent to '/trunk/a/b:3'.
Here are a few options to fix this (I mention the first two only for
completeness, I think they are both bad ideas!):
1) Do nothing. Provoking this situation requires a fairly contrived
setup and the solutions to the problem have their own drawbacks (see
below). But incorrect mergeinfo is still incorrect.
2) Change the behavior of update. If the update target doesn't have
explicit mergeinfo, then set explicit mergeinfo from the repos. Of
course this means that an update on a pristine WC could leave local mods
and worse, it probably won't solve all the problems (it's such a poor
idea I haven't gone much further with it to figure out where it might
fall down).
3) When walking the WC to find a path's nearest parent with explicit
mergeinfo to inherit (or to elide to) DON'T continue into parent paths
unless they share the same working revision. This certainly solves the
problem, but if the merge target tree is not uniformly updated to the
same working revision it means we won't typically walk the WC looking
for inherited mergeinfo. This has a couple of implications. First, it
will increase the number of times we need to contact the server looking
for mergeinfo since we can't rely on the inherited info in the WC.
Second, it will result in more explicit mergeinfo as elision will be
greatly curtailed (crippled really). Lastly, and this is no small
thing, it makes elision/inheritance harder to explain to users than it
already is.
I'd like to implement 3 since all the problems associated with that
solution neatly disappear *if* the merge target is at the same working
revision. So we could just recommend updating the merge target before
merging as standard practice (it doesn't need to be HEAD, it just needs
to be consistent). And again, these problems don't manifest themselves
unless the merge target has subtrees with explicit mergeinfo, so the
problems don't come into play in the "typical" use case for merge.
Any objections or alternate ideas?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-16 15:57:02 CET