[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Thoughts on commit via the out-dated(by irrelevant revisions i.e just by number) mirror

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: Mon, 04 Jan 2010 19:18:45 +0530

Hi All,

Reposting http://mail-archives.apache.org/mod_mbox/subversion-dev/200912.mbox/browser for easy context with recent findings.

Of late we have observed errors like the following when committing via
the european mirror.

<snip>

"The specified baseline is not the latest baseline, so it may not be checked
out."
</snip>

This error happens as the following request part of the commit operation is *served by mirror*.
PROPFIND /svn/repo/!svn/vcc/default HTTP/1.1

We can proxy this request to the Master but we *should not* do that if it is for read operation.

There are couple of ways to identify whether a request is a read request or write.

Approach 1:
May be I can set some persistent data structure at the connection scope remembering the invocation
of prior 'MKACTIVITY' and decide whether it is PROPFIND for commit or 'some read ops'.

Drawback: There could be old clients which can make each request in its own connection and hence would suffer from the above issue.

Approach 2:
Introduce some new request client header 'SVN-ACTION' set to the actual command names so that we can handle this in a fool proof fashion.

Drawback: This most probably happen only on svn 1.7.x so still old clients would suffer from the above issue.

I have Patch for both the approaches in my WC.

Some of my observations with my patch for Approach2:
Combo1:
Master 1.7.x, Slave 1.7.x(SVNAdvertiseV2Protocol On the default setting)
Via ra_neon: it works as expected.
Via ra_serf: *No issue exists at all* as it does *not* use 'PROPFIND at all' in HTTPv2.

Combo2:
Master 1.6.x, Slave 1.7.x(SVNAdvertiseV2Protocol Off)
Both via ra_neon and ra_serf: it works as expected.

As Approach 1 and Approach 2 can co-live, I will post the patch soon after cleaning it up.

So with this collective approach only 'one request/one connection' client(by the way which version of svn or neon is that?) has to suffer.

Thanks
With regards
Kamesh Jayachandran
Received on 2010-01-04 14:50:53 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.