Following up to try and direct a solution... On Wed, Apr 20, 2011 at 03:15, Arwin Arni <ar...@collab.net> wrote: > Hi, > > From what I've read in the responses, I understand that the dav_cache is not > a NON-NULL field... and that neon uses it and serf doesn't. > > I've also not gone deep enough into the code to understand what information > is actually getting stored there, but I do believe this holds some > information that is not known to an out-of-date slave. > > What I see through my experiments (with a master/slave setup where the slave > is lagging behind the master by a commit1 which was done from a working > copy, and a subsequent commit2 is made from the same working copy) is this: > >... >> Case 4 >> svn ci -m "first mod" file --config-option >> servers:global:http-library=serf >> echo "second mod">> file >> svn ci -m "second mod" file --config-option >> servers:global:http-library=neon >> >> Case 4*fails* >> >> Case 5 >> svn ci -m "first mod" file --config-option >> servers:global:http-library=neon >> echo "second mod">> file >> svn ci -m "second mod" file --config-option >> servers:global:http-library=serf >> echo "third mod">> file >> svn ci -m "third mod" file --config-option >> servers:global:http-library=neon >> >> Case 5*fails*. > > > > This leads me to believe that in case 4, when the serf commit clears the > dav_cache, the subsequent neon commit tries to read the cache and upon > finding a NULL, queries the out-of-slave for the information which turns out > to be wrong (wrong as in not the same information that was stored in the > dav_cache prior to the serf commit). If ra_serf sets this information post > the commit, then neon flawlessly picks up this information (which I believe > is known only to the WC and the master and *not* the out-of-date slave) and > cases 4 and 5 PASS.
The core problem here is that the slave is out of date, not what is present (or not) within the dav_cache. In addition, the slave is not responding properly to ra_neon when the latter tries to get the version_url to perform a CHECKOUT. To me, the problem is to fix the slave's response. This may imply a proxied query to the master. > If neon will be taught in the near future how to operate without the > dav-cache, then this is fine. Neon already knows how... that's my point. It is the server which is responding improperly. It is the server which needs to be fixed. Cheers, -g
