On Wed, Jan 03, 2007 at 12:45:32PM -0800, dlr@tigris.org wrote:
> On the merge-tracking branch: Support automatic creation of the sqlite
> merge info index, resulting in automatic migration of repositories
> created by Subversion libraries < version 1.5.
>
Is it fair to say that we're making a policy decision to version the
mergeinfo database separately from the filesystem or repository version
numbers?
I'm not disagreeing that that may be the right thing to do, but I think
we need to seriously consider what kind of policy we want to enforce
here. Currently we have a repository version number and a filesystem
version number, and the meanings currently assigned are as follows:
Repository format 3: Filesystem format number isn't always checked.
Compatible with Subversion 1.0+
Repository format 5: Filesystem format number must be checked.
Compatible with Subversion 1.4+
Filesystem format 1: svndiff0 deltas only
Compatible with Subversion 1.0+
Filesystem format 2: svndiff1 deltas allowed
Compatible with Subversion 1.4+
That's complex enough (even though in practice we end up with only two
combinations to support), so I was thinking that we'd couple the
mergeinfo schema to the repository format number, and just use the
user_version as a flag.
If we don't want to do that, that's fine, but I think we need to make
some decisions about what the correct behaviour should be. For example,
should we be able to upgrade a non-mergeinfo repository to a
mergeinfo-capable one? Does doing so bump either of the existing format
numbers? If not, what happens if we use a pre-1.5 client on the
repository?
One thing that I'm sure I've asked for clarification on at least once
before is whether the mergeinfo SQLite database is intended to be an
index or a primary data store. There was a suggestion at one point that
the svn:merge-info property was only intended to be temporary (which
points to it being the primary store for that information), yet
everything else seems to suggest that it's just an index (including the
comments in the commit you just made).
The reason I'm asking is that it affects how we might choose to answer
some of the questions above. For example, let's say that we aren't
choosing to bump the repository or filesystem formats, and that we are
going to version the mergeinfo schema completely separately (which is
what we have right now); then what happens if we dump/load a
mergeinfo-present repository using svnadmin 1.4? Do we lose the
mergeinfo.db index and retain the (now useless?) svn:merge-info
properties? Does the first access to the repository using a 1.5 client
rescan the properties and recreate the index, or have we permanently
lost information?
> Modified: branches/merge-tracking/subversion/libsvn_fs_util/merge-info-sqlite-index.c
> +/* The version number of the schema used to store the merge info index. */
> +#define MERGE_INFO_INDEX_SCHEMA_FORMAT 1
> +#define MERGE_INFO_INDEX_SCHEMA_FORMAT_STR "1"
I'm sure you could stringify the first to get the second, no need to
repeat the 1/"1".
> +/* Open a connection in *DB to the merge info database under
> + REPOS_PATH. Validate the merge tracking schema, creating it if it
> + doesn't yet exist. This provides both a migration path for pre-1.5
> + repositories, and handles merge info index initialization for 1.5+
> + repositories. */
> +static svn_error_t *
> +open_db(sqlite3 **db, const char *repos_path, apr_pool_t *pool)
If we do choose to retain an explicit create step, I don't think that
comment's accurate (about 1.5+ repositories).
> + /* Validate the schema. */
> + err = check_format(*db);
> + if (err && err->apr_err == SVN_ERR_FS_GENERAL)
> + {
> + /* Assume that we've just created an empty merge info index by
> + way of sqlite3_open() (likely from accessing a pre-1.5
> + repository), and need to create the merge tracking schema. */
> + err = util_sqlite_exec(*db, SVN_MTD_CREATE_SQL, NULL, NULL);
Leaking the error.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Thu Jan 4 23:49:34 2007