[Monotone-devel] Bookkeeping directory format upgrades - thoughts

[Zack Weinberg]

Workspace merge requires some changes to what's stored in _MTN, and
I'd like to open a discussion on the right way to handle such changes
in general.

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.

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 don't have a strong opinion on what's better, but I ask that people
have a look at what I did to work.cc on nvm.wm.api before saying 'of
COURSE we must do it THIS way.'

Comments?

zw