[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH][merge-tracking]Create mergeinfo.db with proper schema in case it does not exist.

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-01-03 21:47:25 CET

On Tue, 02 Jan 2007, Daniel Rall wrote:

> On Tue, 02 Jan 2007, Malcolm Rowe wrote:
>
> > On Thu, Dec 21, 2006 at 06:27:36PM +0530, Kamesh Jayachandran wrote:
> > > Create mergeinfo.db with the necessary schema if the db does not exist with
> > > one.
> >
> > It's annoying that SQLite doesn't give us any way to tell whether it's
> > created a blank database for us, but I'd prefer that we use SQLite's
> > built-in support for user schema version numbers rather than assume that
> > a SQLITE_ERROR return means that we should create the schema afresh.
> >
> > That is, after connecting to the database, issue a
> >
> > PRAGMA user_version;
> >
> > command. If it returns zero, create the database schema and then issue
> >
> > PRAGME user_version = 1;
> >
> > to record that we've created the schema.
> >
> > I'm assuming that we'd tie the mergeinfo schema version to the
> > repository format number, so we wouldn't actually use the user_version
> > value as a proper format number, just a created/not-created indicator.
>
> Good suggestion, Malcolm. How about this implementation?
>
> I do think using some expected format number would be a good way to
> go, so we could more gracefully handle schema changes in the future.

I've committed a variation of this patch to the merge-tracking branch
in r22885, including support for a schema format number which is
specific to the sqlite merge info index (the FSFS and BDB FS backends
appear to use their own format numbers, so a relationship between the
merge info index's format and the FS format is trickier to implement,
and possibly unnecessary).

- Dan

  • application/pgp-signature attachment: stored
Received on Wed Jan 3 21:47:35 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.