[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r997905 - /subversion/trunk/subversion/tests/libsvn_wc/entries-compat.c

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Thu, 16 Sep 2010 22:47:57 +0200

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.

Bye,

Erik.
Received on 2010-09-16 22:48:35 CEST

This is an archived mail posted to the Subversion Dev mailing list.