[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 3 May 2011 20:44:33 -0400

Following up to try and direct a solution...

On Wed, Apr 20, 2011 at 03:15, Arwin Arni <arwin_at_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
Received on 2011-05-04 02:44:59 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.