Greg Stein wrote:
> Julian Foad wrote:
> > I've started looking at moving to a single DB per WC, and written some
> > notes in 'notes/wc-ng/single-db-per-wc'. I haven't looked into the
> > current state of the code yet, other than building it (success) and
> > running it (50% of tests pass, which isn't bad, considering).
>
> I don't know what you mean by "building it" ... the SINGLE_DB define
> is more of a "this area needs to be examined/removed when we shift to
> a single db." And it is NOT exhaustive by any measure whatsoever...
> just where somebody thought to clarify some code that is per-dir
> specific.
Right... All I did so far is define SINGLE_DB and WC_FORMAT=18 (because
we are under the impression that it requires or benefits from
props-in-db).
> If you really want to get hard-core, then #define SVN_SINGLE_DB in
> wc.h and scatter that around. You could define it based on
> SVN_WC__VERSION if you're so inclined (tho tying it into the current
> format invokes upgrading for experimenting).
>
> An area to examine is all of the uses of db_status_obstructed,
> db_status_obstructed_(add|delete). Those should not occur in
> single-db, so anything that sets those status values or checks for
> them is suspect. (I'd #ifdef them away, for example, then patch all
> references).
>
> > Any comments on this "how to upgrade the DB tables" part (copied from
> > that document)?
> >
> > [[[
> >
> > Upgrade: Migration of DB tables from subdir DBs to root DB
>
> I'd suggest using the term "wcroot". That is already in use within
> wc_db. A plain "root" could be confused with other things (eg. repos
> root).
OK, good point.
> > ==========================================================
> >
> > "Move into root's table" means move each row into the same table in the WC
> > root's DB, and we expect no duplicates.
> >
> > "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,
...
]]]
I don't talk about a "Merge" for any other tables. I'll clarify it.
> > REPOSITORY
> >
> > Merge into root's table, which may result in assigning new id's.
> > Change all repos id's accordingly in the other tables being migrated:
> > BASE_NODE.repos_id
> > WORKING_NODE.copyfrom_repos_id
> > LOCK.repos_id
> > # and in tree conflict info?
> >
> > Note: I already have two repos id's in some parts of some of my svn
> > working copies, so this is not purely theoretical.
>
> 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.
> (and note that the table design, and (hopefully) much of the code is
> *intended* to support multi-repos working copies at some point in the
> future, but we've got enough issues to do this transition from 1.6
> without worrying about bringing in such a feature)
>
> > WCROOT
> >
> > Merge into root's table;
> > theoretically we should assign new id's and change them where they
> > appear in other tables, but in practice the id is always 1 so we can
> > just assert that.
>
> Since we are not intending to support multiple working copies from one
> database, then this table should ONLY ever have one row. That row has
> "some integer" for wc_id, and NULL for the local_abspath. The integer
> will/should be 1, but that is not mandated; it is simply an
> implementation artifact from sqlite (maybe they have doc to guarantee
> that it will be 1, but we avoid relying on that; there might be some
> reliance in entries.c and wc_db.c).
OK, we can just ignore this table.
(The hack for wc_id = 1 appears in entries.c (3 places); I can't see it
anywhere else.)
> > BASE_NODE
> >
> > Move into root's table;
> > omit if .kind == subdir
> > change .local_relpath
> > set .parent_relpath
> >
> > WORKING_NODE
> >
> > Move into root's table;
> > omit if .kind == subdir (?)
> > change .local_relpath
> > set .parent_relpath
>
> Generally, ignoring subdir might be okay in these two tables, but the
> not-present value is used/important.
OK, we'll have to figure out what's needed here.
> >...
> > WC_LOCK
> >
> > Move into root's table;
> > change .local_dir_relpath
>
> Nah. This should be empty.
>
> If any locks exist, then 'svn cleanup' should be run. In general,
> locks should *never* exist. Things have to fail pretty hard for this
> to happen. We also shouldn't be using administrative locks all that
> often, either.
OK.
Thanks. I'll fix up the doc and get to work on the code.
- Julian
Received on 2010-07-07 11:39:00 CEST