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