On Saturday 16 July 2005 09:57, Ben Collins-Sussman wrote:
> On Jul 16, 2005, at 8:12 AM, John Peacock wrote:
> > Ben Collins-Sussman wrote:
> >> So we're backtracking a bit, and proposing this more grandiose
> >> vision:
> >> I. Repositories have an accesslog and an errorlog.
> >
> > I'm depressed that I am, to date, unable to articulate to anyone
> > else why I think this design is too limited in scope. My primary
> > objection remains that it assumes that everyone will want to write
> > log _files_ and there is no way to expand it beyond that realm. I
> > fully and freely admit that *most* people will want to log to
> > files, but this design will not permit any other scheme to be added
> > later without completely replacing the interface (i.e. 2.0).
>
> Our proposal states that repos/conf/repos.conf has two variables that
> allow administrators to decide where logfiles live. We can create a
> special value for these variables that means "send to STDOUT". Would
> that satisfy your feature request?
>
> > I'm also not clear why I am unable to describe my reasoning behind
> > the use of a structured log object. It seems so much easier to do
> > this:
> >
> > svn_log_baton_t log = svn_init_log(repos);
> > ...
> > if (level < log.level)
> > svn_log_error(log, level, "message");
> >
> > where the "log" object contains all of the information required to
> > output the log.
>
> How is that different than my proposal, whereby the "svn_repos_t"
> object contains all the information to output to the log? I see no
> difference between
>
> svn_log_error(logobject, level, "message")
>
> and
>
> svn_log_error(reposobject, level, "message")
Sure there is. Having the log baton separated from the repository baton means
that you can potentially use logging for other purposes. For example,
clients could use it for their own debugging purposes (i.e., it might be
easier to get a "traceback" to help track down bugs), or we could provide a
general logfile via /etc/subversion for logging events that don't have a
repository (for instance, someone is repeatedly trying to access a repository
that doesn't exist, or is trying to determine the name of existing
repositories). The latter method means you need to have a repository baton,
which a client doesn't really access directly, and isn't useful when trying
to log access attempts on non-existent repositories.
In our environment, we're very concerned about logging and audit trails. In
fact, it's a requirement placed on us by the Government. Access attempts are
important in determining whether someone is trying to gain unauthorized
access to material. Fortunately, we get this now via Apache2's access/error
logging. I'd like to switch us to svnserve once the path authorization,
SASL, and SSL stuff makes it in, but we also need the ability to see
unauthorized access attempts before making that switch.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 16 16:18:14 2005