Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.

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
Received on 2011-04-20 09:16:16 CEST