Philip Martin wrote on Tue, Apr 08, 2014 at 20:12:26 +0100:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
>
> > Philip Martin wrote on Wed, Mar 19, 2014 at 13:17:08 +0000:
> >> We have:
> >>
> >> - the documented protocol
> >>
> >> (? want-iprops:boolean )
> >>
> >> - the released server implementation of the protocol
> >>
> >> ? want-iprops:boolean
> >>
> >> - the released behaviour
> >>
> >> properties always sent
> >>
> >> - the trunk behaviour
> >>
> >> properties only sent when want-iprops is true
> >>
> >> A third party client could already be using want-iprops with a 1.8
> >> server to get inherited props, even with the broken behaviour.
> >
> > Not our problem. We have no obligation to support third parties who
> > reimplement our protocol. We also have no obligation to make the server
> > accept constructions that no released client ever generated.
>
> So the ra_svn protocol is a private API. Is this a position we have
> taken in the past? I'm not opposed to it but I wasn't aware that it was
> our position.
>
I believe so but don't have a ready reference for it. Perhaps someone
else can weight in on this.
> > If I understand correctly, you're saying that no *released* client[1]
> > ever sent a want-iprops boolean on get-file and get-dir;
>
> Correct.
>
> > so we have zero
> > obligation to support a want-iprops parameter there, period. (To clarify,
> > we have no obligation to support either "?B" or "(?B)" or "?(?B)".)
> >
> > We may choose to support the form that the 1.8.0-1.8.9 server code
> > accepts (that is, "?B"), or we may choose to declare that a bug in
> > 1.8.0-1.8.9.
>
> Does anyone have any opinions about which one we should choose?
>
I propose that we use the "?B" variant but require the boolean to be
false whenever provided. Passing "true" would be an error.
That's basically a win-win situation: we gain the ability to apply the
patch without the burden of having to support or document a
"get-iprops=true" codepath that no released client uses.
This solution presumes that we are free to retroactively change
libsvn_ra_svn/protocol, i.e., that it is a private API (as you say above).
Daniel
Received on 2014-04-08 23:29:27 CEST