Hi Greg, On Thu, Sep 16, 2010 at 10:47 PM, Erik Huelsmann <ehu...@gmail.com> wrote:
> > > On Thu, Sep 16, 2010 at 10:40 PM, Philip Martin < > philip.mar...@wandisco.com> wrote: > >> Erik Huelsmann <ehu...@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.
