On Thu, 04 Jan 2007, Malcolm Rowe wrote:
> 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?
Yeah, it would be. But I'm certainly not set on this route.
> 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.
I'm in favor of this, but thought that it means we need a way to
smuggle the FS backend-specific format number into the libsvn_fs_util.
While I didn't see a way to do this already, my FS-fu is not strong --
perhaps there is one?
However, I forgot that there's also a repository format number. Could
we use it instead?
...
> should we be able to upgrade a non-mergeinfo repository to a
> mergeinfo-capable one?
We need some format of this for Merge Tracking migration -> 1.5.
> 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?
If we go as-implemented, I'd say no. But I'd prefer to tie the merge
info schema format number to the repos or FS backend format number,
for simplicity's sake. The main argument I see against this route --
other than code possibly needing to be written -- is that a merge info
index schema change's need to bump the repos format number might be
seen by users as requiring a dump/load when that is not necessary.
> 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).
Dan Berlin feels we should use the merge info sqlite database as only
an index, storing svn:mergeinfo both in it and in the FS. While I was
originally thinking that we should normalize the svn:mergeinfo data to
only one location to avoid potential synchronicity problems, I've been
feeling more ambivalent recently. (Of course, I'm sure that'll change
the first time the data gets out of sync... ;-)
> 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?
Sounds like a another good reason to conslidate the merge info index's
format number.
> > 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".
Sure. How do you suggest implementing this efficiently?
> > +/* 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.
Thanks, fixed the above two items.
- application/pgp-signature attachment: stored
Received on Sat Jan 6 02:05:22 2007