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 side workaround for svnserve iprops bug > > > > 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 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 > affected server. > > If it the performance was a real show stopper we would have known about this > problem months earlier. >
It's a small patch that's unlikely to break anything (regardless of server version) and may make some users' lives easier. Seems to me like a good backport candidate. > 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 > mod_dav_svn). > > 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... Don't let the perfect be the enemy of the good. Backporting an ra_svn bugfix is an improvement. If people want to backport ra_serf bugfixes, that's great... but the fact that no one backported ra_serf fixes isn't really a good reason to block ra_svn fixes. --- 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 ) ) '.
