[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: mod-dav-svn high level logging compatibility

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2007-12-20 22:16:26 CET

On Dec 18, 2007 8:07 PM, Eric Gillespie <epg@pretzelnet.org> wrote:

> Can I get an answer from some mergeinfo/dav-svn expert?

I know nothing about mergeinfo stuff, sorry.

>
> Need help from dav-svn experts on these 3 items, too:
>
> > - (blame(-merge-sensitive)? '/PATH' rN:N
> >
> > In 1.4 (changed in r23488 r27024 (merge-sensitive)):
> > blame '/PATH'
> >
> > This is actually svn_ra_get_file_revs2/file-revs-report. If
> > this interface is blame-specific, it should be named
> > accordingly. If it is not, the log is wrong.

Yes, I believe that 'blame' is the only command that currently
requests the 'file-revs-report', so it's safe for the server to call
it a 'blame' request. However, older svn clients perform a blame
operation using the 'log-report', so that's why log-report is
described as 'log-or-blame', I think.

> > Finally, things we don't log at all:
>
> > - svn_ra_check_path
> > svn_ra_stat
> >
> > Maybe; are these possible? stat is at least as valuable to
> > log as get_log.

Well, here we get into a debate. These aren't 'high level' client
operations at all, they're things that various client operations do
all the time as part of larger operations. Long ago we decided not
to log GET requests, since we have no idea if it's a web browser, 'svn
cat', or even serf in the middle of a big checkout. And the two
functions above (ra_stat and ra_check_path) are just a lot of PROPFIND
noise... but hey, every client subcommand generates a lot of propfind
noise as well.

The guiding principle was the high-level log would only record
requests that were *clearly* indicative of some high-level client
command. Stray GETs and PROPFINDs are already logged in the normal
apache accesslog. In a nutshell: the high-level log isn't a strict
superset of the accesslog, but rather a mile-high interpretation of
it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 20 22:16:35 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.