On 8/5/05, Greg Hudson <ghudson@mit.edu> wrote:
> On Wed, 2005-08-03 at 10:57 -0400, Charles Bailey wrote:
> > I'm concerned that this may be too narrow a view of logging (i.e. as a
> > tool for <nontechnical>auditing</nontechnical>). While it's certainly
> > true that a log writeable by a local svn client is hackable by a
> > local, I suspect most local users aren't malicious. Given that, I can
> > see reasonable, non-sensitive uses for logging of local activity.
>
> However, applications do not normally log local activity. "ls" does not
> log what directories you look at, etc.. Such information might be
> useful, but normally logging of local activity is expected to be done at
> another layer, such as shell histories or process accounting.
I think we may be looking at the situation from different sides. I
don't disagree that simple applications like 'ls', 'chmod', 'mv' and
the like should be left to process accounting. On the other hand,
applications like 'dump', 'cron', 'sudo', 'pam', and (perhaps
significantly for this list) 'cvs' do log, or at least provide the
option for it. In some cases, the concern is rudimentary auditing, in
others it's saving incremental state, and in yet others it's perhaps
tracking resource usage. My sense is that Subversion falls more into
the latter category than the former.
> I'm not sure if I can provide a compelling justification for this
> attitude in the world of software, but I'm not sure the burden of proof
> is on me. I don't think Subversion should invent jobs for itself beyond
> what the world normally expects of applications in its space. Network
> servers are expected to be able to log client requests; random tools are
> not expected to be able to log everything they do.
Again, I don't disagree with your overall conclusion, but I think that
Subversion isn't a "random tool", in this sense. :) I really don't
think it's a case of inventing a job for Subversion, but one of
deciding whether Subversion will agree to fulfil this (IMHO, but not
necessarily true) reasonable request. Put a different way, 'svn' is
inherently a client; it just happens in some cases (file://) to handle
its own requests.
That said, my argument is more based in a broad view of logging from
Subversion's perspective than in a broad view of the requirements for
the average program. To be a bit more clear (I hope): My sense is
that sufficiently many users would like Subversion to do some sort of
'logical' (i.e. in terms of Subversion operations on Subversion paths)
logging that the developers have agreed it should be implemented.
There are several uses for this. One of these uses is
<non-technical>auditing</non-technical> usage of repositories; for
this use, completeness of the log is a consideration, and it's tough
to guarantee that in the case of locally writeable repositories.
Therefore, <non-technical>reliable</non-technical> logs may well
require access via a server. However, there're still other use cases
(some of which I've noted before) that don't have this requirement.
If Subversion's logging can be implemented so as to satisfy both
groups of users, what's the harm? Perhaps it's complexity -- if it
becomes a real limiting factor, that in itself may be enough to
justify scrapping "general" logging. Perhaps it's concern for
confusion about what is and isn't "reliable" -- I'd argue that this is
better addressed by documentation than by omitting the feature.
Perhaps it's a general concern that the more Subversion does, the more
users will expect -- I'd argue that you haven't crossed the boundary
of what's reasonable yet; burn that bridge when it's behind you.
Perhaps it's the feeling that Subversion should in general draw its
feature narrowly to minimize the chance of future maintenance
headaches -- this may be a philosophical divergence; I'm essentially
arguing for the most inclusive approach that's practical.
I'm not sure this meets the burden of proof for which you're looking,
but I do hope it helps to clarify why I think logging of file://
activity in Subversion is a reasonable option.
--
Regards,
Charles Bailey
Lists: bailey _dot_ charles _at_ gmail _dot_ com
Other: bailey _at_ newman _dot_ upenn _dot_ edu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 8 16:52:22 2005