On Wed, Jul 7, 2010 at 05:37, Julian Foad <julian.foad_at_wandisco.com> wrote:
>...
>> > "Merge into root's table" means we move the row into the root's table,
>> > unless a row that's identical apart from its id is already present, in which
>> > case we use the existing row's id.
>>
>> What do you mean "id"? That column doesn't exist in any of the tables.
>> Do you mean its primary key? (which is typically a composite key)
>
> I mean the thing called "id" which is the primary key in two tables.
> (I'm not sure whether it's strictly called a "column" but it looks like
> one.) From wc-metadata.sql:
>
> [[[
> CREATE TABLE REPOSITORY (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
> ...
> CREATE TABLE WCROOT (
> id INTEGER PRIMARY KEY AUTOINCREMENT,
> ...
> ]]]
Ah. Whoops. I'm so used to using "repos_id" and "wc_id", that I forgot
they were simply called "id" in their tables :-P
>...
>> This shouldn't happen. As I recall, all working copies need to be part
>> of the same repository. If there is a different repos, then it is a
>> "detached" working copy living within another (a manual or
>> externals-based checkout within another).
>>
>> If 'svn switch --relocate' can be used on a subtree *without*
>> detaching it, then that certainly affects the above point.
>
> The issue is: same repos, different repos id (= 2), after using "svn
> switch --relocate". Don't know if that's how it should work, but that's
> how it does work.
>
> Since I have relocated my WC like this, any new versioned directories
> that have been created since then have got the new repos URL, but with
> repos-id = 1:
>
> [[[
> $ sqlite3 .svn/wc.db "select * from REPOSITORY"
> 1|https://svn.apache.org/repos/asf|13f79535-47bb-0310-9956-ffa450edef68
> 2|https://svn.eu.apache.org/repos/asf|13f79535-47bb-0310-9956-ffa450edef68
>
> $ sqlite3 notes/rename-tracking/.svn/wc.db "select * from REPOSITORY"
> 1|https://svn.eu.apache.org/repos/asf|13f79535-47bb-0310-9956-ffa450edef68
> ]]]
>
> Hence the need to merge the tables as described.
I see. This is probably because we don't garbage-collect the repos_id
values. There might not be any references to repos_id==1, yet the row
remains.
(theoretically, we might have been able to do relocate by altering
REPOSITORY, but in the future, subtree relocates would be nice... that
implies multiple rows, so we may as well leave its current operation)
>...
> (The hack for wc_id = 1 appears in entries.c (3 places); I can't see it
> anywhere else.)
It would be nice to eliminate this one day...
Cheers,
-g
Received on 2010-07-07 17:16:59 CEST