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 1:
 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=neon

 Case 1 succeeds.

 Case 2:
 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=serf

 Case 2 succeeds

 Case 3
 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

 Case 3 succeeds.

 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.

If neon will be taught in the near future how to operate without the dav-cache, 
then this is fine. For now however, I think we should not clear this cache but 
rather populate it with the relevant information so that ra_layers can be 
switched at will.

Regards,
Arwin Arni

Reply via email to