On Jul 15, 2005, at 11:02 AM, Greg Hudson wrote:
>
> But this brings up another point: your svn_repos_write_accesslog()
> (which is much too long of a name for a commonly-called function,
> incidentally) should take a variable argument list. Then, at least
> the
> top-level apr_snprintf can be avoided whenever the log level is too
> low,
> and there is no performance issue in the common case where the
> arguments
> are readily available.
Excellent idea, consider me sold. Will do.
>
>> * PROBLEM: logging errors or requests not associated with
>> repositories.
>>
>
> I tentatively agree with your later conclusion that only access logs
> should be per-repository, and that we should leave error logging to
> the
> servers.
>
I'm not sure what this plan looks like, though.
Are we talking about tossing *all* mention of errorlog (and loglevel)
in the public API, and just make the API talk about per-repos
accesslog? (In which case, mod_dav_svn continues logging errors to
apache's errorlog, and svnserve grows some private errorlog/loglevel
ability that goes into /etc/subversion/...)
Or, should we still have a notion of a 'shared' errorlog in /etc/
subversion, usable via a public API? (The public API just wouldn't
make use of svn_repos_t; it would be more generically available to
all servers.)
I'm thinking that the latter option is still more attractive, because
the sorts of errors that mod_dav_svn logs into apache's system are
very low-level and unfriendly. I'd like mod_dav_svn to be able to
log more intellible, svn-specific errors into an svn-specific errorlog.
>
>> * PROBLEM: lots of processes all trying to write to logfiles.
>>
>
> In Unix land, at least, if you open a file for append on a local
> filesystem, write() is atomic. So generally logging wins because the
> log messages fit within the buffer size and are written out with a
> single write().
Hm, I wonder if we're okay on windows as well... or if APR makes any
such atomic write guarantees in general...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 15 18:37:04 2005