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

Re: Proposal for Logging in Svnserve

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2005-07-13 22:46:22 CEST

On Wed, Jul 13, 2005 at 05:29:13PM +0200, nick vajberg wrote:
> A few opinions:
>
> In general, I'd like the logging facility to be
> independent of server. That is, logging should work
> the same way whether running httpd or svnserve or
> something else.
> That way, if the logging API got pluggable, even svn
> under httpd could benefit from stuff like networked
> logging (rather than polluting the apache log)
>

Ideally, the code could be instrumented with logging/trace
calls that behaved appropriately (though perhaps differently)
under both svnserve and httpd. That may be exactly what you're
getting at.

> >> 4.1 Customizable Log Format
>
> Make it fixed so people can easily write tools that
> parses and aggregates/presents the log info in various
> ways. The alternative is to write API's for traversing
> the log, but that's not worth it IMO.
>
> >>4.3 Support for syslogd
>
> Note that there are syslogd ports for win32. At any
> rate, please don't even consider using the NT event
> log; files rule in this case.
>
> >> 4.2 Support more verbose output and debug tracing.
>
> I disagree with brane that logging and debug logging
> are different animals - that's just a load of crap.
>
> More than once have I turned on the debug level in
> stuff like Hibernate without even restarting the
> server running it.

My guess is that your complex Java application actually
has two logging facilities:

1.) Application-level audit-logging of things like "user
logged in", "user logged out", "user changed password", and
perhaps even "user ran report Foo with criteria Bar".

This probably gets logged in a database table (or tables)
in a structured or semi-structured way, and has all kinds
of application-level tools built around it.

If your application doesn't have this, it probably isn't
SOX compliant.

2.) log4j, for troubleshooting, monitoring, debugging,
tuning, etc.

>
> The log4j levels are good examples and it works really
> well in practice.

log4j is great at (2), it's not-so-great at (1), especially
in environments where the audit trail is extremely important
(think SOX compliance).

> >> 4.5 XML Logging format
>
> Don't go there. Please.

I agree that for (2) it's usually a bad idea. For (1), it
is occasionally the least-evil solution.

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 13 22:47:00 2005

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.