Re: client side workaround for svnserve iprops bug

Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:

> I would vote "+1 to backport" right here and now, but I'm a bit confused
> by the patch: it seems the client and server send and expect a bare
> boolean, whereas libsvn_ra_svn/protocol calls for a boolean wrapped in a
> tuple.
>
> (i.e., '( foo bar true ) ' vs '( foo bar ( true ) ) '.

It's ugly. I believe the want-iprops flag was added to the get-dir and
get-file commands before the get-iprops command was added. Our client
now uses get-iprops excusively and never sends want-iprops with get-dir
or get-file. I suspect want-iprops should not have been released.

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.

How do we fix this mess? We could change the server implementation of
the protocol to match the documentation, but that would risk breaking
third party clients. We could declare want-iprops to be an error and
remove it, that also risks breaking third party client. We could change
the documentation of the protocol to match the released implementation,
but that would mean accepting the "? foo" form rather than "(? foo)" and
I seem to recall that the later is preferred as it's easier to extend.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*