> -----Original Message-----
> From: Philip Martin [mailto:philip.martin_at_wandisco.com]
> Sent: dinsdag 18 maart 2014 19:32
> To: dev_at_subversion.apache.org
> Subject: client side workaround for svnserve iprops bug
> philip_at_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 data.
> An implementation bug causes svnserve to mishandle the nominally
> optional want-iprops flag for get-dir and get-file with the result that
> the server keeps sending properties even when the client doesn't want
> them, this can be a serious performance regression. (The want-iprops
> flags was documented/released with 1.8 but isn't used by the released
> client which uses get-iprops instead.) The problem is fixed on trunk
> and nominated for 1.8 with 1578853.
> We could add a client-side workaround for buggy servers, see the patch
> below. We could do this for trunk, 1.8, even 1.7. Is it a good thing
> to do?
If think affected users should upgrade (or downgrade) their server to a not
If it the performance was a real show stopper we would have known about this
problem months earlier.
For 1.8 a few more user reports can convince me that it would be useful to
add it, but for svnserve it would be easier to fix a single server than all
the clients. (It isn't that connected to all kinds of other modules as
Adding a protocol changing patch to 1.7 to improve performance against a
specific set of 1.8 servers... I don't think we should go that route. In
that case we could better spend our time backporting many of the far more
important move bugs in 1.8 (several that can corrupt wc.db) that were fixed
months ago from trunk... Or the ra_serf fixes...
Received on 2014-03-18 19:43:12 CET