"witty subject line about logging feature"

Several of us had some more real-time discussion in IRC today about
logging design. It was a bit confusing, though, because it seems that
we still haven't agreed on general goals. To quote ghudson:

    "Perhaps the problem here is that we're designing from the bottom
    up. Everyone has in their head an idea of what kind of logging
    might be added, and is proposing a framework which might allow that
    kind of logging. But people aren't writing down (with any
    concreteness) what's in their heads. So we get a lot of bikeshed
    discussion about the framework, but that's the wrong place to
    start."

So let's try this from the top-down. What problem(s) are we trying to
solve?

Here's what the Chicago office thinks the main problem is:

    * svnserve currently has no logging at all, and apache's logging is
      far too low-level to be comprehensible.

    * both svn server processes need a way to log "high-level" actions:

        - what conceptual requests were made (i.e. update, commit, etc.)
        - what URLs were accessed, by whom, from what IP
        - what errors or warnings might have happened

And here's the Chicago office's design goals:

    A. Make it easy for any svn-related program to log messages to a
       common place -- not just server implementations, but *any*
       svn-related program. This makes it easier to find/manage logs,
       and rotate them.

    B. Make it possible for svn-related programs to log messages to
       private places too, should they wish.

    C. Make it possible to integrate with OS-level logging facilities
       (e.g. syslogd and win32 logging subsystem)

I think ghudson is trying to solve the same problem, but has
very different design goals:

    A. Only svnserve needs logging. mod_dav_svn can just log new
       things to apache's already existing logs.

    B. svnserve shouldn't reinvent logging, it should intergrate with
       existing OS logging facilities.

I don't think the problem is in question. But perhaps we should try
to come to a consensus on our design goals?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 22 00:58:25 2005