On 13 April 2015 at 17:41, Bert Huijben <b...@qqmail.nl> wrote: >> -----Original Message----- >> From: Ivan Zhakov [mailto:i...@visualsvn.com] >> Sent: maandag 13 april 2015 14:53 >> To: dev@subversion.apache.org; Bert Huijben >> Subject: Re: svn commit: r1673170 - in /subversion/trunk/subversion: include/ >> libsvn_fs/ libsvn_fs_base/ libsvn_fs_fs/ libsvn_fs_x/ libsvn_ra_local/ >> libsvn_repos/ mod_dav_svn/ svnserve/ tests/libsvn_ra/ > >> The proper solution would be add new DAV property like >> "has-dead-props", advertise it support using capability header and >> then request it from client instead of "deadprop-count". >> >> What do you think? > > The problem is that currently all subversion clients that perform an 'svn ls > -v' (including TortoiseSVN) > use the existing request. New clients that know about this problem simply > don't ask for this property. > If we do it as you suggest we don't help old clients and we don't help new > clients, while old > clients don't have a way to access this integer. > I understand you intention to improve performance for users with older clients, but with introducing such protocol hacks your may end with situation when you need time machine for fix bugs/problems.
Your 'svn ls -v' fix (r1673153) is really nice and simple. We could easily backport it to 1.8.x and 1.9.x. Users who experience this problem should upgrade to newer version. > I think we should define a new thing (capability, header, property, whatever) > if we ever decide > that we are interested in the integer. Given that today we aren't even > interested in the boolean > value (but do spend a whole lot of server CPU obtaining it - Minutes in my > tescases), I > don't think it is likely that we ever want the real value, as the other ra > layers don't provide > the value either. Command line client doesn't interested in it, but we expose has_props through API and clients like TortoiseSVN uses it. > > The best solution would be to do as you suggested, but in that case we need a > time machine (or > otherwise we should do nothing at all and keep mod_dav as slow as it is > today). > > > In this already bad case I think it is better to tell new servers that we > want the real value > in the future instead of now spending minutes of server CPU and IO time on a > request that > could end in seconds, when nobody is interested in the result :( > I think that making server side to report bogus data (99 as dead prop count) is protocol violation. I'm -1 on it. I think we should implement proper server side fix or remove it since we already fixed command line client. -- Ivan Zhakov
