On 01/06/2010 06:58 PM, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Kamesh Jayachandran [mailto:kamesh_at_collab.net]
>> Sent: woensdag 6 januari 2010 14:00
>> To: dev_at_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
Received on 2010-01-06 16:22:11 CET