On 13 April 2015 at 17:41, Bert Huijben <bert_at_qqmail.nl> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
>> Sent: maandag 13 april 2015 14:53
>> To: dev_at_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
Received on 2015-04-13 17:13:54 CEST