> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Thursday, July 05, 2007 2:55 PM
> To: Paul Burba
> Cc: SVN Dev; Daniel Rall; Kamesh Jayachandran
> Subject: 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
I don't understand what Rule #2 is about, specifically what
"syntactically optimized away" means. Could you give an example or try
and alternate explanation?
> Using negated merge ranges, you could store:
>
> "/A:1" on A_COPY and all directories beneath it for whom every
> child is present.
When you say "and all directories" you don't mean explicitly right, but
via mergeinfo inheritence I assume?
> "/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.
a.k.a. The present siblings of the missing path get inheritable
mergeinfo.
> This leaves as implicit on the missing children of FOO merge
> info of "/A:1,3-4", which is what you want, right?
Yes, in my example, A_COPY\D\H\psi would inherit A:1,3-4 post-merge,
i.e. the same mergeinfo it had pre-merge.
> 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.
I don't see any problems with this solution. The only drawback I see is
that it makes the human readability of svn:mergeinfo a bit more
difficult. Non-inheritable mergeinfo is already going to force lots of
changes, tacking this on is only a marginal increase in work (I think!).
Anyone else have any thoughts on this?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 5 22:16:56 2007