On Thu, 2008-11-13 at 13:11 -0800, pburba_at_tigris.org wrote:
> Author: pburba
> Date: Thu Nov 13 13:11:33 2008
> New Revision: 34184
>
> Log:
> One small step towards mergeinfo sanity; no more explicit mergeinfo
> on a WC-to-WC move/copy destination unless the source had some.
Paul,
You asked me if I could sanity-check the theory of this change. I have
had a go. It depends on understanding exactly what the functional change
is. I wrote down what I think the change in actual behaviour is. I've
got a feeling I'm a bit off the mark here. Please correct me. I wrote
down three use cases to understand the ideal (correct) behaviour so that
I have something against which to analyze the actual behaviour. Have I
understood the ideal behaviour correctly?
Then I wrote down what results would be produced before and after the
change, for each of the use cases. If I got the change in behaviour very
wrong, ignore them and I'll re-think.
In all of this I was just thinking about what it means. I didn't try to
run tests to discover how it actually behaves. Sorry if I've gone off on
a wrong track because of that.
...
The change in behaviour
-----------------------
The effects of this change (r34184) are limited to scenarios in which
the effective mergeinfo on the source node being copied is not available
in the WC. This can only happen when the source node inherits its
mergeinfo and the (grand)parent from which it inherits is not in the WC.
Previously:
if mergeinfo of source is not available in the WC:
destination gets empty mergeinfo.
Now:
if mergeinfo of source is not available in the WC:
destination inherits mergeinfo from its new parent.
Use cases
---------
Here are some use cases for different kinds of WC-to-WC copy. In these
use cases, "project" means the tree rooted at "/trunk" or "/branches/*".
Assume only whole-project merges have been done until now, so explicit
mergeinfo only exists on the nodes "/trunk" and "/branches/*".
The ideal correct result is stated in each case, not compromised by
restricting it to what's available in the WC, so presumably this result
should be the same as what a server-side copy already does.
Use case 1: Make a new branch of the project.
(Copy a node with explicit mergeinfo.)
$ svn co $REPOS root-wc
$ svn copy root-wc/trunk root-wc/branches/my-branch
The (explicit) mergeinfo on source should be copied to dest verbatim,
because exactly the same node-revs have been merged into dest as into
source.
In this case, the mergeinfo on source is always available in the WC.
Use case 2: Copy a subtree within the project.
(Source inherits, and dest could inherit from the same place.)
$ svn co $REPOS/branches/my-branch/docs docs-wc
$ svn copy docs-wc/en docs-wc/fr
Dest should get explicit mergeinfo identical to source's effective
mergeinfo. (I don't think that's the same as the effective mergeinfo it
would get by inheriting, as that would be like source's effective
mergeinfo except with all references to ".../en" replaced by ".../fr".)
Use case 3: Copy a subtree from another branch.
(Source inherits, but dest cannot inherit from the same place.)
$ svn co $REPOS/trunk/docs trunk-docs-wc
$ svn co $REPOS/branches/my-branch/docs my-docs-wc
$ svn copy trunk-docs-wc/fr my-docs-wc/fr
Dest should get explicit mergeinfo that is a verbatim copy of source's
effective mergeinfo.
The change in results
---------------------
Previously:
Use case 1:
Always RIGHT.
Use case 2:
WRONG. A later merge of all outstanding changes from "en" to "fr"
should work as the copy-from line of history is "natural" history.
Whole-project merges may still work, as this sub-tree didn't exist
before. But a merge from "en" in another branch would try to repeat
existing changes.
Use case 3:
WRONG. Whole-project merges will try to repeat existing changes.
Now:
Use case 1:
Always RIGHT.
Use case 2:
WRONG.
Use case 3:
WRONG: Dest says it has all the changes that have been merged from
sub-tree "fr" in other branches in previous whole-project merges. That
part is OK: there weren't any such changes or else this dest would
already exist. But it also says it doesn't have any of the changes that
actually were merged into "fr" in the source branch before this copy.
Whole-project merges will try to repeat existing changes.
Conclusion
----------
The change results in less explicit mergeinfo being produced, which is
reckoned to be a good thing in its own right.
In terms of the correctness of merging, the change still produces wrong
results in the same cases as before, but wrong in a different way. It is
not clear whether the results are better or similar or worse than
before.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=983067
Received on 2008-12-11 23:28:39 CET