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