subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kamesh Jayachandran <kam...@collab.net>
Subject Thoughts on commit via the out-dated(by irrelevant revisions i.e just by number) mirror
Date Mon, 04 Jan 2010 13:48:45 GMT
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


Mime
View raw message