You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Arwin Arni <ar...@collab.net> on 2011/04/19 17:57:44 UTC
[PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
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
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
Posted by Greg Stein <gs...@gmail.com>.
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" <cm...@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 <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
Posted by Greg Stein <gs...@gmail.com>.
On Apr 19, 2011 12:10 PM, "Hyrum K Wright" <hy...@hyrumwright.org> wrote:
>...
>
> False. This is a *cache*, meaning, if it is NULL you don't lose any
> information, it may just take longer to get that information. If the
> cache is NULL, neon will populate it as needed for increased
> performance.
>
> Note that the cache is inherently NULL the first time you use neon
> when checking out a working copy, and yet it works. :)
The cache is populated during checkout, so ra_neon actually populates it
right from the start. If you switch between RA layers, ra_neon will populate
it for nodes changed during an update (generally).
Cheers,
-g
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Tue, Apr 19, 2011 at 10:57 AM, Arwin Arni <ar...@collab.net> wrote:
> Hi All,
>
> NODES.dav_cache in wc.db is always set to NULL in serf.
>
> Is it intentional?
Yes. Serf does not require this cache.
> 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*.
False. This is a *cache*, meaning, if it is NULL you don't lose any
information, it may just take longer to get that information. If the
cache is NULL, neon will populate it as needed for increased
performance.
Note that the cache is inherently NULL the first time you use neon
when checking out a working copy, and yet it works. :)
-Hyrum
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
Posted by Greg Stein <gs...@gmail.com>.
Following up to try and direct a solution...
On Wed, Apr 20, 2011 at 03:15, Arwin Arni <ar...@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
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
Posted by Arwin Arni <ar...@collab.net>.
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
Re: [PATCH] NODES.dav_cache in wc.db is always set to NULL in serf.
Posted by Greg Stein <gs...@gmail.com>.
ra_serf uses HTTPv2 which does not use the dav_cache. ra_neon has not been
upgraded to use the new protocol.
When ra_serf talks HTTPv1, it *may* use dav_cache, but we may have just left
that out and taken the speed hit (I don't recall)
Cheers,
-g
On Apr 19, 2011 11:58 AM, "Arwin Arni" <ar...@collab.net> 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