Ben Collins-Sussman wrote:
> So Karl and I had another long chat, and now we're both thinking that
> perhaps this logging design conversation has wandered down a path that
> we're not so happy with.
>
> My last conclusion was based on ghudson's suggestion: "bah, apache
> already has errorlogs, let's just implement something similar within
> svnserve's private code."
>
> But now we're thinking that maybe this isn't so good.
>
> First, errors are generally just as specific to repositories as
> network requests. So if we think it's a good idea to have
> repos-specfic accesslogs, it's likely just as useful to have
> repos-specific errorlogs.
>
> Second, svnserve and apache aren't the only users of svn_repos_t.
> Other processes such as svnadmin, svnlook, viewcvs, or even 'svn
> file:///' may all want to log errors. This implies that it would be
> beneficial to have a public API for error-logging alongside the one
> for access-logging. (Which is what I originally drafted.)
>
> So we're backtracking a bit, and proposing this more grandiose vision:
>
> I. Repositories have an accesslog and an errorlog.
>
> A. repository logs live in repos/logs/. By default, a
> repository has an accesslog and errorlog in there.
>
> B. repositories grow their own configuration file in
> repos/conf/, named 'repos.conf'. For now, the only thing in
> that file are two variables stating where accesslog and
> errorlog live.
Hm. I wonder how Unix distros are going to handle log rotation for logs
that are spread all over the place like this. Seems like a most annoying
setup.
How about taking the default log file location for all repositories from
a config file in /etc/subversion, and using the repository name (perhaps
configured per-repo, UUID could be default) as the basename of the log
file? Then it would be easy to put all logs into, e.g.,
/var/log/subversion and handle the rotation in one swell floop.
(Of course log rotation isn't the only issue, _finding_ all the logs is
quite important, too).
> II. Repos-specific public API for accesslog and errorlog
>
> A. svn_repos_open() parses repos/conf/repos.conf, and thus knows
> where the logs are. (If there is no repos.conf it creates
> one.)
>
> B. API allows user to identify itself to the svn_repos_t, so
> that terms like "mod_dav_svn" and "svnserve" can show up in
> logs.
>
> C. API to write to errorlog and accesslog both take a
> svn_repos_t argument.
O.K.
> The objections people have brought up previously:
>
>
> 1. "What about errors (or access requests) that happen before we have
> an svn_repos_t?"
>
> Our feeling is that each process can decide how to handle those
> things on its own. A process may choose to:
>
> * not log such events at all
>
> * log them in a sensible global location
>
> * log them in location determined by a process-specific .conf
> file (such as svnserve.conf)
So does this imply that, for non-repo-specific logging, we'd need a
_different_ logging API?
It seems natural to me to use the same logging API for everything,
perhaps using a null svn_repos_t for non-repository-specific logs.
You'd probably want an option to pipe everything into the same
error/access log file, too, regardless of the repository being used.
> 2. "But mod_dav_svn is already logging errors to apache's errorlog."
>
> We can change mod_dav_svn to:
>
> * log repos-inspecific errors in apache's errorlog, and
> repos-specific ones in the repository's errorlog.
Sort of forces you to sniff through at least two (if not 4) log files in
order to trace a request.
> * give administrators a choice: "would you like repository
> specific errors to be logged in the repository's errorlog,
> apache's errorlog, or both?"
I suspect that we won't be able to get away with not having such an
option in the long run.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 16 01:19:55 2005