On 01/06/2010 07:32 PM, Philip Martin wrote:
> Kamesh Jayachandran<kamesh_at_collab.net> writes:
>
>
>> This patch is with respect to the original thread
>>
>> http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/browser
>>
> This one I suppose:
>
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201001.mbox/<4B41F1BD.8090209@collab.net>
>
Yes, thanks for correcting.
> It includes:
>
> "We can proxy this request to the Master but we *should not* do
> that if it is for read operation."
>
> Does something go wrong if the read operation goes to the master or is
> it just an efficiency thing?
>
It can go wrong in the following scenario,
If Slave is out-dated still checkouts from it should work without any
confusion. If we always proxy 'PROPFIND' to Master we may get some new
revision numbers operated against the Slave and hence loads of confusion.
>
>> Once this patch gets committed I can commit the mod_dav_svn change to
>> handle the original commit via outdated proxy issue.
>>
> Have we seen this other patch yet?
>
Not yet, Find it in the attachment. This fix expects the new header
'SVN-ACTION', if it does not exist makes use of 'connection persistence'
to find the commit activity and proxy selectively.
>
>> This Patch revs the following public APIs,
>>
>> 'svn_client_uuid_from_url', 'svn_client_open_ra_session' and 'svn_ra_open3'.
>>
>> For ra_neon and ra_serf layers it sets the http client header
>> SVN-ACTION with the concerned svn command name.
>>
> The "SVN-ACTION" name is already used by the operational logging code,
> I don't know if this matters.
>
>
May be in the *future* when the new client is everywhere we can change
the operational logging code to make use of this header.
May be I can change this to something SVN-COMMAND if there are serious
objections.
>> With& Without this patch mergeinfo_test-8 fails both over ra_neon and
>> ra_serf.
>>
>> If there are no objections I will commit this change in next 2 days.
>>
> This ties an RA session to a single operation name -- that's a new
> restriction on RA sessions isn't it? It may be the way our clients
> work at present but clients don't have to work like that, a single
> session could be used for multiple operations. A client may not even
> know what operations are going to be carried out until some time after
> the session has been opened.
>
May be we can provide an RA API to change the command names prior to
using the pre-existing ra_session for new command.
With regards
Kamesh Jayachandran
Received on 2010-01-06 15:23:24 CET