You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by eh...@apache.org on 2010/09/16 22:07:28 UTC
svn commit: r997905 -
/subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c
Author: ehu
Date: Thu Sep 16 20:07:27 2010
New Revision: 997905
URL: http://svn.apache.org/viewvc?rev=997905&view=rev
Log:
Fix one of two remaining SVN_WC__NODES failures (manifesting itself twice).
* subversion/tests/libsvn_wc/entries-compat.c
(TESTING_DATA): Add NODES (working_node) data.
Modified:
subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c
Modified: subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c?rev=997905&r1=997904&r2=997905&view=diff
==============================================================================
--- subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c (original)
+++ subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c Thu Sep 16 20:07:27 2010
@@ -381,6 +381,95 @@ static const char * const TESTING_DATA =
" null, null, null, 0, null, null, '()', 0); "
" "
#endif
+#ifdef SVN_WC__NODES
+ /* Load data into NODES table;
+ ### op_depths have not been calculated by me yet;
+ the value 1 is just 'good enough' to make the nodes WORKING nodes. */
+ "insert into nodes values ("
+ " 1, 'I', 1, '', 2, 'some/dir', 2, 'normal', 'immediates',"
+ " 0, null, 'dir', 2, " TIME_2s ", '" AUTHOR_2 "', null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J', 1, '', null, null, null, 'normal', 'immediates',"
+ " 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-a', 1, 'J', null, null, null, 'normal', null,"
+ " 0, null, 'file', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-b', 1, 'J', 2, 'some/dir', 2, 'normal', 'infinity',"
+ " 0, null, 'dir', 2, " TIME_2s ", '" AUTHOR_2 "', null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-b/J-b-a', 1, 'J/J-b', 2, 'another/dir', 2, 'normal', 'infinity',"
+ " 0, null, 'dir', 2, " TIME_2s ", '" AUTHOR_2 "', null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-b/J-b-b', 1, 'J/J-b', null, null, null, 'normal', null,"
+ " 0, null, 'file', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-c', 1, 'J', null, null, null, 'not-present', null,"
+ " 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-c/J-c-a', 1, 'J/J-c', null, null, null, 'not-present', null,"
+ " 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-d', 1, 'J', 2, 'moved/file', 2, 'normal', null,"
+ " 1, null, 'file', 2, " TIME_2s ", '" AUTHOR_2 "', '$md5 $ " MD5_1 " ',"
+ " '()', 10, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-e', 1, 'J', null, null, null, 'not-present', null,"
+ " 0, 'other/place', 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-e/J-e-a', 1, 'J/J-e', null, null, null, 'not-present', null,"
+ " 0, null, 'file', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-e/J-e-b', 1, 'J/J-e', null, null, null, 'not-present',"
+ " null, 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-e/J-e-b/Jeba', 1, 'J/J-e/J-e-b', null, null, null, 'base-deleted',"
+ " null, 0, null, 'file', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-f', 1, 'J', null, null, null, 'normal', 'immediates',"
+ " 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'J/J-f/J-f-a', 1, 'J/J-f', null, null, null, 'base-deleted',"
+ " 'immediates', 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'K', 1, '', null, null, null, 'base-deleted', null,"
+ " 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'K/K-a', 1, 'K', null, null, null, 'base-deleted', null,"
+ " 0, null, 'file', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'K/K-b', 1, 'K', null, null, null, 'base-deleted', null,"
+ " 0, 'moved/away', 'file', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'L', 1, '', null, null, null, 'normal', 'immediates',"
+ " 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'L/L-a', 1, 'L', null, null, null, 'not-present', 'immediates',"
+ " 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+ "insert into nodes values ("
+ " 1, 'L/L-a/L-a-a', 1, 'L', null, null, null, 'not-present', 'immediates',"
+ " 0, null, 'dir', null, null, null, null, '()',"
+ " null, null, null, null, null);"
+#endif
"insert into actual_node values ("
" 1, 'I', '', null, null, null, null, null, 'changelist', null, "
"'" I_TC_DATA "', null, null, null, null);"
Re: svn commit: r997905 - /subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c
Posted by Philip Martin <ph...@wandisco.com>.
Erik Huelsmann <eh...@gmail.com> writes:
> However, the UPDATE_RECURSIVE_BASE_REPO query doesn't take any of that into
> account and simply rewrites all repo_ids to be the new repo to relocate to.
> That doesn't seem correct though: if other nodes had different repository
> sources, those should probably be excluded from relocation, no?
Agreed.
--
Philip
Re: svn commit: r997905 - /subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c
Posted by Erik Huelsmann <eh...@gmail.com>.
Hi Greg,
On Thu, Sep 16, 2010 at 10:47 PM, Erik Huelsmann <eh...@gmail.com> wrote:
>
>
> On Thu, Sep 16, 2010 at 10:40 PM, Philip Martin <
> philip.martin@wandisco.com> wrote:
>
>> Erik Huelsmann <eh...@gmail.com> writes:
>>
>> > We're now back to a single failure. It's in the relocation-verification
>> code
>> > in db-test.c (line 1505). With the half-hour I've spent so far, I wasn't
>> > able to locate it, but I have to move to other business now. Hopefully
>> > you'll be able to find it.
>>
>> It's the difference between the old STMT_UPDATE_BASE_RECURSIVE_REPO
>> and the new STMT_RECURSIVE_UPDATE_NODE_REPO. The first updates
>> non-null repo_ids while the second updates repo_ids that match the old
>> repo_id. This makes a difference when a node has a non-null repo_id
>> that doesn't match the the old repo_id.
>>
>> I'm not sure whether the pre-relocate db is valid, and if it is I'm
>> not sure which of the relocate algorithms is correct.
>>
>
> The latter query (the one which verifies the repo_id) is the one I wrote. I
> did so intentionally: from the description of the copyfrom_* fields in the
> WORKING_NODE table, I couldn't but conclude they may be referring to a
> different repository. Since the new query is updating both BASE and WORKING,
> I thought verification of the old repo_id to be required. Additionally, what
> happens if -for whatever reason- 1 working copy contains references to
> multiple repositories? The former query will rewrite everything to be part
> of the same repository. Hence, I think the former query is flawed.
>
> I hope the original author (Greg?) has something to say about it.
>
Just checked who originally wrote the
STMT_UPDATE_RECURSIVE_BASE/WORKING_REPO query for use with relocate. Turns
out to be you indeed.
The fact that the old copyfrom_* fields have a repo_id column indicates to
me that you're provisioning the option to store the fact that a file has
been copied off a different repository. The fact that you store (in BASE) a
repo_id for every base node (instead of one per wc) probably means that
you're provisioning to have multiple repository sources for a single wc.
However, the UPDATE_RECURSIVE_BASE_REPO query doesn't take any of that into
account and simply rewrites all repo_ids to be the new repo to relocate to.
That doesn't seem correct though: if other nodes had different repository
sources, those should probably be excluded from relocation, no?
What's your view on this?
Bye,
Erik.
Re: svn commit: r997905 - /subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c
Posted by Erik Huelsmann <eh...@gmail.com>.
On Thu, Sep 16, 2010 at 10:40 PM, Philip Martin
<ph...@wandisco.com>wrote:
> Erik Huelsmann <eh...@gmail.com> writes:
>
> > We're now back to a single failure. It's in the relocation-verification
> code
> > in db-test.c (line 1505). With the half-hour I've spent so far, I wasn't
> > able to locate it, but I have to move to other business now. Hopefully
> > you'll be able to find it.
>
> It's the difference between the old STMT_UPDATE_BASE_RECURSIVE_REPO
> and the new STMT_RECURSIVE_UPDATE_NODE_REPO. The first updates
> non-null repo_ids while the second updates repo_ids that match the old
> repo_id. This makes a difference when a node has a non-null repo_id
> that doesn't match the the old repo_id.
>
> I'm not sure whether the pre-relocate db is valid, and if it is I'm
> not sure which of the relocate algorithms is correct.
>
The latter query (the one which verifies the repo_id) is the one I wrote. I
did so intentionally: from the description of the copyfrom_* fields in the
WORKING_NODE table, I couldn't but conclude they may be referring to a
different repository. Since the new query is updating both BASE and WORKING,
I thought verification of the old repo_id to be required. Additionally, what
happens if -for whatever reason- 1 working copy contains references to
multiple repositories? The former query will rewrite everything to be part
of the same repository. Hence, I think the former query is flawed.
I hope the original author (Greg?) has something to say about it.
Bye,
Erik.
Re: svn commit: r997905 - /subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c
Posted by Philip Martin <ph...@wandisco.com>.
Erik Huelsmann <eh...@gmail.com> writes:
> We're now back to a single failure. It's in the relocation-verification code
> in db-test.c (line 1505). With the half-hour I've spent so far, I wasn't
> able to locate it, but I have to move to other business now. Hopefully
> you'll be able to find it.
It's the difference between the old STMT_UPDATE_BASE_RECURSIVE_REPO
and the new STMT_RECURSIVE_UPDATE_NODE_REPO. The first updates
non-null repo_ids while the second updates repo_ids that match the old
repo_id. This makes a difference when a node has a non-null repo_id
that doesn't match the the old repo_id.
I'm not sure whether the pre-relocate db is valid, and if it is I'm
not sure which of the relocate algorithms is correct.
--
Philip
Re: svn commit: r997905 - /subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c
Posted by Erik Huelsmann <eh...@gmail.com>.
Hi Philip,
On Thu, Sep 16, 2010 at 10:07 PM, <eh...@apache.org> wrote:
> Author: ehu
> Date: Thu Sep 16 20:07:27 2010
> New Revision: 997905
>
> URL: http://svn.apache.org/viewvc?rev=997905&view=rev
> Log:
> Fix one of two remaining SVN_WC__NODES failures (manifesting itself twice).
>
> * subversion/tests/libsvn_wc/entries-compat.c
> (TESTING_DATA): Add NODES (working_node) data.
>
>
We're now back to a single failure. It's in the relocation-verification code
in db-test.c (line 1505). With the half-hour I've spent so far, I wasn't
able to locate it, but I have to move to other business now. Hopefully
you'll be able to find it.
Bye,
Erik.