Philip Martin wrote on Tue, Apr 08, 2014 at 20:12:26 +0100: > Daniel Shahaf <d...@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
