On 01/06/2010 06:58 PM, Bert Huijben wrote:
-----Original Message-----
From: Kamesh Jayachandran [mailto:kam...@collab.net]
Sent: woensdag 6 januari 2010 14:00
To: dev@subversion.apache.org
Subject: [PATCH] Make svn clients indicate their operation name to
backend(right now only to DAV)
Hi All,
This patch is with respect to the original thread
http://mail-archives.apache.org/mod_mbox/subversion-
dev/201001.mbox/browser
Once this patch gets committed I can commit the mod_dav_svn change to
handle the original commit via outdated proxy issue.
This Patch revs the following public APIs,
'svn_client_uuid_from_url', 'svn_client_open_ra_session' and
'svn_ra_open3'.
First We need this change as an easy means to tell the server what the
client's intensions are.
We are not bothered about the value of SVN-ACTION except when it is
'commit'.
If the user uses old client(<1.7) we have a fall back mechanism in place
to detect.
This fall back mechanism *relies* on connection persistence which is not
a reliable assumption as per Justin.
So we have this per request logging.
I have a few high level questions about this patch:
Why do you rev svn_client_uuid_from_url?
I would think that that function is a high level API, so it would be an
operation by itself.
(looking at svn_client.h) What should I put in there as client that just
needs the uuid or verify that the repository exists?
You can put anything you like that identifies the new operation you come
up with.
Suppose some gui svn app has a feature by name 'merge aware revision
graph' a custom implementation can open the ra_session with the string
'merge-aware-revision-graph' So that server admin can identify it if needed.
"checking-uuid-for-visualization-to-my-great-users"?
Yes, it can be any string.
I don't think we should rev the svn_client_ API for this specific change
here; especially since older clients will not pass anything anyway.
libsvn_client should fill that high level operation for library users or the
value is of no use on the server.
We need to rev this as we do not want to know 'micro operations like
getting UUID' rather 'SOME custom command which makes use of this
self-contained utility function'.
And it should never be forwarded to master servers as the uuid is supposed
to be constant per repository.
Client never *knows* about the master.
This implementation is just one Broad level identification tied to sub
requests helping with big operation.
(BTW. the api is new in 1.7, so it needs no revving at all)
Yes it checked it seemed to be there since 2003.
Then on to the rest of the patch:
For ra_neon and ra_serf layers it sets the http client header SVN-ACTION
with the concerned svn command name.
If the operation is a plain string that can be set by any future client, how
is the server to understand what the user wants? How can the server
understand a new 'shelve' command we might add in Subversion 1.9?
Server do not bother about at it, It just gets the clue only when the
operation is 'commit'.
It *can* be useful for some server admin to keep track of how his server
resources are utilised.
May be if he sees some operation by name
'SERVER-RESOURCE-INTENSIVE-OPERATION' as its SVN-ACTION header he can
deny the connection atleast temporarily till he equips his server to
handle this intensive operation.
mod_dav_svn only knows RA operations and doesn't understand high level
commands; we would have to add this knowledge.
Shouldn't the individual RA operations tell whether the user needs access to
the master or the slave?
No ra sessions do not even know the existence of slave. Only proxy knows
that it is a proxy *not* anyone else.
Thinking a bit further about that last issue... What if the session is
reused for e.g. requests like 'svn info', 'svn update' and then a 'svn
commit'.
Our standard client libsvn_client can't do this, but other clients can
certainly do that.
There is nothing in the ra api that forbids using it that way, but just
specifying a high level operation at open time doesn't tell enough about
what the clients application intent is.
May be we can implement the svn_ra_redescribe or something to tell its
new intensions.
Maybe we should just add a boolean to requests indicating whether to forward
to a master? That seems like a much simpler solution, that we could possibly
port back to older subversion releases.
No need, clients can/should not know anything about Master.
With regards
Kamesh Jayachandran
