On Tue, Jul 6, 2010 at 15:24, Julian Foad <julian.foad_at_wandisco.com> 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.
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).
> ==========================================================
>
> "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)
>
> 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.
(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).
> 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.
>...
> 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.
>...
Cheers,
-g
Received on 2010-07-06 22:49:49 CEST