As cmpilato pointed out here,
http://svn.haxx.se/dev/archive-2007-04/0709.shtml
we have a problem with inheritable mergeinfo and "missing" paths in the
current merge-tracking implementation.
THE PROBLEM:
A merge target may have children that are "missing" due to the
following:
A) Authz restrictions
B) Deleted via the OS rather than svn
C) Sparse checkouts
D) Child is switched - Yes, the path isn't really missing, but the
impact is the same.
(Any other causes of "missing" paths I'm forgetting?)
Merging to a target with a missing child path results in the missing
child (which obviously never had any changes merged into it) incorrectly
inheriting the merge info set on the merge target path. This is not a
big problem if the merge didn't effect any paths within the missing
tree, but if it did then the mergeinfo set on target is incorrect.
POTENTIAL SOLUTIONS (in increasing order of insanity):
A) Currently all mergeinfo is inheritable. Kamesh came up with the idea
non-inheritable mergeinfo. If a merge target has a missing child, the
child's immediate parent (which may be the merge target itself) gets
non-inheritable mergeinfo and the missing child's existing siblings get
"normal" inheritable mergeinfo. The merge target itself, assuming it
was not the immediate parent of the missing child, gets inheritable
mergeinfo just as it does on trunk today.
C) Go back to the pre r25085 behavior and don't set/update mergeinfo on
a target if *any* paths are skipped as missing. This is the "just don't
do that" solution. It's certainly easy to implement :-) There may even
be some validity to this approach in cases A, B, and C -- one could
argue that the user is making a bad choice for a merge target. But for
D I think we need a real solution.
C) Scrap out entire inherited mergeinfo model and set mergeinfo on
*every* path. I mention this only for completeness' sake, since it is
*a* solution.
OPEN QUESTION:
How will any work on tree-conflicts
http://svn.haxx.se/dev/archive-2007-05/0303.shtml
http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts.txt alter our
handling of skipped paths? I don't know that it really impacts which
potential solution to use. Even if a skipped path where to result in a
conflict, once that conflict was resolved we are still faced with the
original problem.
WHAT CAN BE DONE IMMEDIATELY:
As mentioned above, the case where a child is missing because it is
switched (D) is a bit different from A, B, and C in that the path isn't
really "missing", it's present, but in name only. Because of this, a
partial fix within the existing MT implementation (where switched path
mergeinfo doesn't inherit from WC ancestors or elide) is possible -- see
http://svn.haxx.se/dev/archive-2007-04/0678.shtml. I have a patch for
this but I'm reworking it.
~~~~~
Any opinions on the suggested solutions or alternatives appreciated,
thanks,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 20 19:02:31 2007