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
