Re: [Monotone-devel] Bookkeeping directory format upgrades - thoughts

[Nathaniel Smith]

On Mon, Jul 24, 2006 at 12:09:34AM -0700, Zack Weinberg wrote:
> The precise change I'm looking at right now is called "make _MTN/work
> be a revision, not a changeset" and the code I have currently written
> (over on nvm.workspace-merge.api) does this by killing off both
> _MTN/work and _MTN/revision in favor of one file called _MTN/workrev
> which has exactly the format of a revision.  This works fairly nicely
> for the present change, but may not work so well for potential future
> changes; in offline conversation Nathaniel suggested introducing a new
> file with a format version number in it, which might indeed make
> sense, but currently feels like YAGNI to me.

Hmm, it doesn't really set my YAGNI-sense tingling.  The problem with
not having a systematic method like this is, say we make another
format change later, to a new-new version -- we have to make sure our
migration code can handle upgrading both old and new versions to the
new-new version.  This is a pain when we've all forgotten how exactly
the old->new migration worked anyway, and we now have to go figure out
where exactly it is hiding and rewrite it.  Better to just put it into
a single function whose purpose is clearly labeled (e.g., by being
called "upgrade_workspace_v0_to_v1" ;-)).  It also makes it much
easier to figure out when we can remove this code -- if v2 turns out
to be simply incompatible, no migration possible (as happened with
0.26), then we want to be able to detect that and explain to the
user, but we can rip out the v0->v1 code at the same time.

> Now, it's not just about how to store the data on the disk; it's also
> about the upgrade path.  I see basically two ways to do it.  We can
> upgrade an old-format workspace on the initial app.allow_workspace()
> call - this has the advantage that we could put the migrate code all
> in one place like we do for database schema upgrades, and would go
> nicely with the format version number; the disadvantage is that people
> might find their workspaces suddenly unreadable by older versions of
> monotone, when they hadn't done anything that they expected to make
> on-disk changes.  The other approach is to preserve code to read the
> old format as well, and switch to the new format only when we have to
> write the relevant data.  That's what I did on nvm.wm.api.  It has
> just the converse advantages and disadvantages: it gives people a
> potentially longer window in which they can drop back to an older
> version, and upgrading happens on what people understand is a write
> operation; but it means the upgrade code is intertwined with the rest
> of work.cc, and it doesn't play particularly nice with a version
> number.

I was imagining that we'd do exactly what we do for db schema changes:
  -- if monotone discovers that you're trying to use a workspace of a
     different version, then it errors out and explains you have to
     migrate your workspace format.  (Or, if the workspace format is
     what's newer, explains that you need to upgrade monotone itself.)
  -- an explicit command like "mtn upgrade workspace" may be run to
     migrate the workspace to the latest-and-greatest.  (Cf. "mtn db
     migrate".)

The advantages are that we can handle workspaces that are too new as
well as too old, everything is obvious to the user, and we don't have
to think too hard about what sorts of partial compatibility can be
achieved.

-- Nathaniel

-- 
"...All of this suggests that if we wished to find a modern-day model
for British and American speech of the late eighteenth century, we could
probably do no better than Yosemite Sam."