On Jul 27, 2005, at 6:10 PM, Nicolás Lichtmaier wrote:
>
>
>> 2. mod_dav_svn learns to write "high level" logs, in addition to
>> the
>> existing low-level ones.
>>
>> --> a number of apache developers have told me about
>> legitimate
>> methods to write 'custom' svn messages into apache's
>> accesslog.
>>
>>
>> 3. nothing else writes logs.
>>
>> --> Logs aren't interesting or important (or trustworthy, or
>> even necessarily complete) unless we're talking about
>> server programs talking to clients over a network.
>>
>
>
> I don't like it. It means logging is specific to the way the
> repository is served.
Exactly. Logging is a property of the *server*, not the repository.
> Wouldn't it be better to make logging independent of that?
We already some variants of this idea, and ended up not liking them.
Greg Hudson (and others) pointed out that the only trustworthy,
interesting logging comes from servers. That's why we're advocating
a server-centric design here, not a repository-centric design.
For example: apache might serve a dozen different websites using
VirtualHost. We don't see separate logfiles for each site, we see
logfiles for *apache*. The same idea would go for svnserve. It has
a single logfile, even though it may be serving a dozen
repositories. The history of a single repository can be found by
parsing the log.
With a single logfile, you can view *all* accesses in one place, and
also extract individual repository access histories. If each
repository had its own logfile, then doing a security audit would be
a real pain; you'd have to hunt down each logfile and scan it
separately.
> What about repositories which are used with several access methods?
>
Then they get both apache and svnserve logs of activity. Bonus.
(Besides, this is a small edge case. How many projects can you name
that do this?)
> Although I'm not a developer I'd like to propose a different approach:
[...]
> Local file access is logged two! The argument about it having no
> meaning... has no meaning! The "security" of the log system would
> be no better than the security of the repository itself. Somebody
> who uses file:// access doesn't care about security, and he still
> may want to see how his repository is used.
As Greg Hudson already said, this is why process accounting tools exist.
>
> All of this means logging to simple files. System logging is
> usually useful for system events. Who would like to see each "svn
> up" as an informational event in Windows' event viewer?
Many people. The whole appeal of Greg's proposal is that OS logging
facilities exist for more than just the OS -- they're supposed to be
used by "well behaved" applications. They're accessible and
parseable by multiple tools. We're trying to make svnserve into a
"well behaved" program, rather than have it reinvent the wheel.
> [...] Simple file-logging has several advantages: Logs are the same
> cross-platform, and Subversion is heavily cross-platform.
Subversion is still "cross platform" and "portable". As mentioned
earlier, there's nothing "unportable" about using an OS-specific
service. That's what APR does already in many cases. What's
portable here is that logging is happening on every platform, not the
means used to achieve the logging.
> Tools can be written to accesss them, process them and give
> statistics.
You can argue that it would be convenient to write a single tool
which parses svnserve logs on every OS. But then we can counter-
argue that tools to parse win32 and syslogd events *already* exist
and are standard.
The other disadvantage of implementing our own private logfiles is
the issue of workload: as discussed in earlier threads, this is not
a trivial task. It's a big wheel to reinvent. We have to worry
about formatting flexibility, atomic log writes, and log rotation
too. Or, we can use existing systems that already do this.
It seems like you've countered with the older proposal we discussed
last week, and all I've done is rehash the same criticisms that made
us dislike it. Are you persuaded?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 2 00:31:50 2005