Re: [RFC] Mergeinfo and missing children of merge target

Paul Burba wrote:
> ...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?

The first thing I thought up as a solution to this problem involves
supporting inverse (or negated) merge ranges. Rules of interest:

   Rule #1: a revision range prefixed by a hyphen is negated
   Rule #2: no uninheritable ranges may be syntactically optimized away

Using negated merge ranges, you could store:

   "/A:1" on A_COPY and all directories beneath it for whom every
   child is present.

   "/A:1,3-4,-3-4*" on any directory FOO under A_COPY whose children
   are not all present (A_COPY\D\H, in your example).

   "/A:1" on children of FOO which are present.

This leaves as implicit on the missing children of FOO merge info of
"/A:1,3-4", which is what you want, right?

I'm largely thinking aloud here, and not very close to the problem space, so
there is probably a gargantuan hole in my logic here. But I figured I'd
throw this out there for peer review.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand