Bert Huijben wrote on Tue, Mar 18, 2014 at 19:42:29 +0100:
>
>
> > -----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
> 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 ) ) '.
Received on 2014-03-18 23:20:59 CET