> -----Original Message-----
> From: Ivan Zhakov [mailto:i...@visualsvn.com]
> Sent: maandag 13 april 2015 17:13
> To: Bert Huijben
> Cc: dev@subversion.apache.org
> 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/
>
> 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.
(Not answering any question here, or trying to convince you... just writing
down my reasoning)
I like to think that mod_dav implements just the RA api when we have
is_svn_client as TRUE (or HTTPv2 when applicable), while we try to provide a
good read-only DAV client when it is not. (It is only a writable DAV client
after explicitly enabling autoversioning)
So in general I try to make mod_dav behave as the other ra layers, instead of
just trying to map everything on DAV and leaving it there.
In this case that would make ra_dav -like on the log report- get the worst
behavior of all ra layers, while it is in my opinion the most popular/mostly
used ra layer.
I don't see which minority of users (if any) we help by aiming for DAV
compatibility over svn ra layer usability/performance here.
(BTW: I don't think we ever documented what the deadprop-count value in the
subversion xmlns represents... It just happens to be what it is today, and is
just used as a boolean since r858587, committed in 2006 to fix issue 2151 "'svn
ls' is slow over ra_dav")
Bert
