Re: client side workaround for svnserve iprops bug

2014-04-08 Thread Daniel Shahaf
Daniel Shahaf wrote on Tue, Apr 08, 2014 at 21:28:17 +: > Philip Martin wrote on Tue, Apr 08, 2014 at 20:12:26 +0100: > > Daniel Shahaf writes: > > > 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 > >

Re: client side workaround for svnserve iprops bug

2014-04-08 Thread Daniel Shahaf
Philip Martin wrote on Tue, Apr 08, 2014 at 20:12:26 +0100: > Daniel Shahaf writes: > > > Philip Martin wrote on Wed, Mar 19, 2014 at 13:17:08 +: > >> We have: > >> > >> - the documented protocol > >> > >> (? want-iprops:boolean ) > >> > >> - the released server implementation of

Re: client side workaround for svnserve iprops bug

2014-04-08 Thread Philip Martin
Daniel Shahaf writes: > Philip Martin wrote on Wed, Mar 19, 2014 at 13:17:08 +: >> We have: >> >> - the documented protocol >> >> (? want-iprops:boolean ) >> >> - the released server implementation of the protocol >> >> ? want-iprops:boolean >> >> - the released behavio

Re: client side workaround for svnserve iprops bug

2014-03-19 Thread Daniel Shahaf
Philip Martin wrote on Wed, Mar 19, 2014 at 13:17:08 +: > Daniel Shahaf 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 boolea

Re: client side workaround for svnserve iprops bug

2014-03-19 Thread Philip Martin
Branko Čibej writes: >> 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

Re: client side workaround for svnserve iprops bug

2014-03-19 Thread Philip Martin
Philip Martin writes: > 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. That's not right, it would likely break all clients. I don't think we can do that. I think we either cha

Re: client side workaround for svnserve iprops bug

2014-03-19 Thread Branko Čibej
On 19.03.2014 14:17, Philip Martin wrote: > 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. A protocol implementation bug is still a bug. We fix it and describe the fix in the relea

Re: client side workaround for svnserve iprops bug

2014-03-19 Thread Philip Martin
Daniel Shahaf 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 (

Re: client side workaround for svnserve iprops bug

2014-03-18 Thread Daniel Shahaf
Bert Huijben wrote on Tue, Mar 18, 2014 at 19:42:29 +0100: > > > > -Original Message- > > From: Philip Martin [mailto:philip.mar...@wandisco.com] > > Sent: dinsdag 18 maart 2014 19:32 > > To: dev@subversion.apache.org > > Subject: client sid

RE: client side workaround for svnserve iprops bug

2014-03-18 Thread Bert Huijben
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: dinsdag 18 maart 2014 19:32 > To: dev@subversion.apache.org > Subject: client side workaround for svnserve iprops bug > > phi...@apache.org writes: > > > Author: philip

client side workaround for svnserve iprops bug

2014-03-18 Thread Philip Martin
phi...@apache.org writes: > Author: philip > Date: Tue Mar 18 12:57:22 2014 > New Revision: 1578853 > > URL: http://svn.apache.org/r1578853 > Log: > Make svnserve recognise when the client does not want inherited > properties. This fixes a performance problem with 1.8 servers > sending too much d