Re: [Monotone-devel] Release/Migration plan for monotone?

[Nathaniel Smith]

On Fri, Mar 10, 2006 at 10:32:47AM +0100, Markus Meyer wrote:
> we are currently using Monotone 0.18 for version control in our
> business, which works great for us. However, from reading the webpage,
> it seems that there have already been some new versions released which
> require migration of the database or even a complete rebuild of the
> version history. So I'm asking: what is the recommended way to handle
> this? Should we try to always keep our version of Monotone up to date to
> minimize the risk of data corruption, or is it possible to wait for a
> 1.0 version? Will the 1.0 version be able to import databases from 0.18
> without problems? What is the release plan for Monotone (i.e. will there
> be a date set for 1.0, or does it follow a "it is ready when it is done"
> approach")?

We're a little... irrational... about data corruption.  If you run
into a case where you suspect data corruption, we'll probably more or
less drop everything else to figure out what's up.  We've been known
to write special migration code for single users, even... (E.g., see
branch net.venge.monotone.colinux-path-fixups...)

Obviously, the 0.18 -> now upgrade path is not as well tested as the
0.18 -> 0.19 -> ... -> now upgrade path, simply because fewer people
have used it, so I can't guarantee there aren't some strange subtle
bugs lurking that no-one has found.  However, the data migration
system is designed to support arbitrary upgrades in a reasonably
trustworthy way (it just runs all the migration steps in sequence, so
should be quite similar to that well-tested path), and I know that the
basic migration works, because there's a regression test that has a
standard database in every historical database format, and migrates
them all all the way to modern monotone in one jump.  (And then checks
that everything came through correctly.)

In theory, therefore, migration is fully supported from any version
since 0.4 (released September 2003).  The test mentioned above was
added more recently than that (and no-one's dragged out an old g++
2.95 build environment to reconstruct old test databases), so some of
that early stuff isn't tested as well, but 0.18 is no sweat...

The official way to migrate from version 0.x to 0.y is to look in the
file UPGRADE shipped with 0.y, find all the lines of the form "if you
are upgrading from 0.<blah> or earlier" that apply, and do all the
things they tell you to do.  NEWS and UPGRADE aim to together be
complete, concise guides to what you need to know about new versions.

While migration is well-supported, I'd still recommend tracking
monotone releases more closely, just because things improve very
quickly.  The current code is much better than 0.18's code, and that
gap will only increase :-).  We're also not very well equipped to
help with problems that far back, if you run into any.  Since our
releases have historically been very reliable, and we're still in
alpha mode, bugs in old versions are generally low priority -- gives
us more time to spend looking ahead :-).  But, whatever works.

The biggest problems with upgrading are changes in netsync, and data
rebuilds of the sort that will occur with 0.26.  Both require your
team to upgrade in tandem.

Re: 1.0 -- Graydon already wrote a nice reply here.  I probably would
give a few details differently, but definitely, the basic goal is to
get something as stable as possible, as soon as possible.  But no
sooner :-).  The end seems to be just starting to come up over the
horizon...

> Again, thanks for providing Monotone!

Glad to hear it's working for you!  Good luck!

-- Nathaniel

-- 
Linguistics is arguably the most hotly contested property in the academic
realm. It is soaked with the blood of poets, theologians, philosophers,
philologists, psychologists, biologists and neurologists, along with
whatever blood can be got out of grammarians. - Russ Rymer