> -----Original Message-----
> From: Paul Burba [mailto:pburba@collab.net]
> Sent: Wednesday, June 20, 2007 1:02 PM
> To: SVN Dev
> Subject: [RFC] Mergeinfo and missing children of merge target
>
> 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
I originally intended this to mean:
A1) Authz *DESTINATION* restriction - The child path affected by the
merge is missing because of an authz restriction. This is still an open
issue.
But this closely related case is also worth mentioning here:
A2) Authz *SOURCE* restriction - The child path affected by the merge is
not missing, but we don't have access to the source so the merge cannot
be performed for this child. But since we have full control over the
destination we can do one of the following:
* If the child has no explicit mergeinfo at the start of the merge, then
add mergeinfo on the child which is equivalent to whatever it would have
inherited *prior* to the merge.
* If the child has explicit mergeinfo at the start of the merge, then
leave it unchanged.
> B) Deleted via the OS rather than svn
Here again we are dealing with two different cases:
B1) Deleted file - because file props are stored in the parent
directory, if that directory is still present we can set overriding
mergeinfo on it.
B2) Deleted dir - Currently this just errors out with something like:
# Delete merge_tests-1.restricted\D\H via the OS
>svn merge -r2:6 %SURL%/A merge_tests-1.restricted
--- Merging r3 through r6:
Skipped missing target: 'merge_tests-1.restricted\B\E'
U merge_tests-1.restricted\D\G\rho
Skipped missing target: 'merge_tests-1.restricted\D\H\omega'
Skipped missing target: 'merge_tests-1.restricted\D\H\psi'
Skipped missing target: 'merge_tests-1.restricted\D\H'
..\..\..\subversion\libsvn_wc\props.c:1473: (apr_err=155005)
svn: Failed to load properties from disk
..\..\..\subversion\libsvn_wc\lock.c:977: (apr_err=155005)
svn: Directory 'merge_tests-1.restricted\D\H' is missing
..\..\..\subversion\libsvn_wc\lock.c:977: (apr_err=155010)
svn: Directory 'merge_tests-1.restricted\D\H' is missing
A2 and B1 were fixed in r25514 (grrr...or so I thought, there is still a
problem, working on that right now). I don't think B2 needs fixing, you
delete part of your WC via the OS and bad things are going to happen.
So I propose we leave this as-is. The fact that merge works in the OS
deleted file case (B1) is really just a side effect of fixing A2. I
could certainly tweak it so both B cases simply fail and require that
the WC be updated to successfully merge. Thoughts?
> C) Sparse checkouts
>
> D) Child is switched - Yes, the path isn't really missing,
> but the impact is the same.
In r25565 part of the problem with switched children was fixed. Now
switched children without mergeinfo prior to the merge get mergeinfo set
which is a combination of the merge being performed and any inherited
mergeinfo from the repository for the switched path. So at least the
repository location CHILD is pointing to will get the correct mergeinfo.
The location CHILD is overriding is still wrong however, and that brings
me to the "big" problem...
> 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.
...I see a problem that inheritable mergeinfo ranges won't solve.
Putting aside implementation details for a moment, everything is fine if
the missing child's immediate parent has no mergeinfo, if we are only
adding new revision ranges, or if we are removing non-inheritable
ranges: Set non-inheritable ranges on that parent and done! But what
about reverse merges of inheritable revision ranges?
For example, say we have a standard greek tree repos, where, with a wide
open authz:
r2 - 'A' copied to 'A_COPY'
r3 - text mod to 'A/D/H/psi'
r4 - text mod to 'A/D/H/rho'
r5 - merge -r2:4 A A_COPY, puts mergeinfo '/A:1,3-4' on 'A_COPY'
Now set up authz to give us no access to '/A_COPY/D/H/psi', checkout a
fresh WC, and merge -r4:2 from 'A' to 'A_COPY':
>svn merge MT\A MT\A_COPY -r4:2
--- Merging r4 through r3:
U MT\A_COPY\D\G\rho
Skipped missing target: 'MT\A_COPY\D\H\psi'
'A_COPY/D/H/psi', which we have no access to, has no explicit mergeinfo,
but it inherits r1,3-4 from it's parent 'A_COPY/D/H'. But this merge
removes that mergeinfo and regardless of inheritable/non-inheritable
mergeinfo, we can't override 'A_COPY/D/H/psi''s mergeinfo.
Solutions:
1) During the commit detect the situation and set the appropriate
mergeinfo on 'A/D/H/psi'. I hate this idea because we are violating the
authz rules.
2) If a merge tries to change a path that is inaccesible because of an
authz restriction, then set mergeinfo on that path's immediate parent
(if it had none prior to the merge) that is equal to it's inherited
mergeinfo at the start of the merge. i.e., '/A/D/H:1' on 'A_COPY/D/H'
in the above example. If the parent had explict mergeinfo then don't
change it. Maybe even explicitly warn the user that something is wrong:
>svn merge MT\A MT\A_COPY -r4:2
--- Merging r4 through r3:
U MT\A_COPY\D\G\rho
Skipped missing target: 'MT\A_COPY\D\H\psi'
Warning: Unable to update mergeinfo on 'MT\A_COPY\D\H' due to missing
children.
This limits the incorrect mergeinfo to the subtree we don't have full
acess too. This might not be too crazy, *if* this is not a common
scenario. Someone (dlr?) pointed out to me that setting up your authz
in such a way that user will checkout a partial tree is not that likely.
Any thoughts or alternative solutions?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 2 23:07:05 2007