I believe that when ra_serf touches a node, the dav_cache will be set to
null. wc_db basically enforces that.
On Apr 19, 2011 12:11 PM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
> ra_serf in trunk, speaking HTTPv2 with the server, doesn't make use of the
> dav_cache. But I can see how that might be a problem when switching
between
> serf and neon, because neon *does* consult the dav cache (which in your
> case, I'm guessing, must be stale).
>
> At a minimum, if ra_serf isn't going to consult the dav cache, it should
at
> least be sure to invalidate whatever is stored therein so as not to trip
up
> neon.
>
>
> On 04/19/2011 11:57 AM, Arwin Arni wrote:
>> Hi All,
>>
>> NODES.dav_cache in wc.db is always set to NULL in serf.
>>
>> Is it intentional?
>>
>> If not attached patch would fix it.
>>
>> Why I am concerned?
>>
>> I was testing one scenario(master-slave setup) which failed becuase of
>> NODES.dav_cache being NULL.
>>
>> Scenario:
>>
>> I was trying to understand r900797(Commit where subsequent commits(from
same
>> WC) to the same out-dated proxy(out-dated only after the first commit)
was
>> made to succeed via <D:apply-to-version/>)
>>
>> For some time I could see it fail with trunk binary later reduced with
the
>> following cases,
>>
>> 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*.
>>
>>
>> Effectively once your working copy is used with serf you can not go back
to
>> neon for this particular *CASE*.
>>
>> Regards,
>> Arwin Arni
>
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Received on 2011-04-19 18:14:54 CEST