On Fri, 2011-07-01, Paul Burba wrote:
> Paul Burba wrote:
> > Julian Foad wrote:
> >> I will just ask once more: as a matter of principle, are we comfortable
> >> it's OK to provide only an indication that "the server did in fact do
> >> this for you this time", but not to have a way of finding out in general
> >> whether the server is capable of doing this?
> >
> > On further reflection, I think using a server capabilities check is
> > the better approach:
[...]
> > I'll add the new capability if there are no objections.
>
> Done http://svn.apache.org/viewvc?view=revision&revision=1141981
Hi Paul. That looks good. I have some queries and suggestions about
the details, not all related specifically to this change, which I'm
attaching in the form of a patch (not to be committed as-is), which I'd
like your feedback on.
I wonder, do any callers really want to receive invalid mergeinfo? Is
this optional just because the server-side processing is slow and some
callers don't care?
I noticed some functions take an 'ignore_invalid_mergeinfo' parameter;
that confused me because I thought it was referring to the same thing
but instead it refers to a syntatically invalid svn:mergeinfo property
value. By contrast, what we're dealing with in the 'invalid_inherited'
case is mergeinfo that's syntactically valid but semantically invalid or
at least redundant because it refers to non-existent path-revs. I
wonder if it would be worth either using a different term (I know there
are loads of terms already, which can be confusing in itself) or
otherwise working towards simply eliminating this kind of mergeinfo from
our attention altogether by never exposing it and never giving the
caller the choice.
- Julian
Received on 2011-07-08 19:04:59 CEST