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