Hi Greg,
On Thu, Sep 16, 2010 at 10:47 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
>
>
> On Thu, Sep 16, 2010 at 10:40 PM, Philip Martin <
> philip.martin_at_wandisco.com> wrote:
>
>> Erik Huelsmann <ehuels_at_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.
Received on 2010-09-16 23:15:21 CEST