"Daniel Patterson" <danpat@danpat.net> writes:
> How important is the accuracy of the log? If the client is supplying
> the critical information, it's vulnerable to tinkering, maliciously
> or otherwise. How much of a headache will it be if a non-official
> client sends an 'operation_name' with a typo?
No trouble at all, as long as the server admins are aware of this.
Remember that the server cannot be fooled about what the client
actually did -- the low-level requests cannot be disguised. The
client can claim an inaccurate overall name for the operation(s)
comprised by these low-level requests, or fail to supply a name at
all, or claim it wanted something it didn't really want, but that's
it. The client cannot actually fool the server into not knowing what
work it (the server) did.
All this is true for CVS 'history' as well: the client could falsely
claim to have "released" a working copy, for example.
I feel like a common misunderstanding is going to keep coming up in
this thread, and I want to head it off right now:
For judging server *workload*, we don't need any protocol additions.
The server already knows what it does, and it could log these things
(mod_dav_svn already does so in the Apache HTTPD logs, in fact). But
that's a different feature, and is not addressed by this patch. This
patch is about logging the conceptual operations the client intended
to perform (commit, update, merge, diff, blame, etc). Most clients
share a large set of such conceptual operations; you can see this
reflected in the libsvn_client API.
In order to do this kind of logging, we need the elient to tell us
what operation it intended to perform. There is no way around this,
as far as I can see. After all, if a client wants claim "merge" when
it actually did "diff", there is no way for the server to detect the
lie, since those two look the same over the wire.
People want both kinds of logging, for different reasons. This patch
addresses one kind. Please do not flog it for not addressing the
other kind. They're two different problems.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 6 23:11:53 2005