Re: [Monotone-devel] workspace migration improvements - no more database

[Nathaniel Smith]

On Tue, Sep 05, 2006 at 02:11:44PM -0700, Zack Weinberg wrote:
> I just pushed a revision of the workspace migration code which makes
> it no longer need the database.  You should now be able to do "mtn
> migrate_workspace" in an old-format workspace without specifying -d,
> and your options file should come through intact.  I've beefed up the
> testing of this to make sure it doesn't break again.

Cool.

> As a consequence of this change, the "new_manifest" field of the
> revision in _MTN/revision is now *always* fake.  [Without the
> database, it's impossible to compute a "correct" one; if I'd made
> migration put a fake id there but not everything else, we would risk
> things coming to rely on a real id there and thus breaking rarely -
> only after a migration event - a very hard bug to track down.]  For

It's not the cheapest thing in the world to to calculate, and never
useful.  (Generally, it's the hash of some manifest quite different
from the one the workspace actually represents.)

> great defensiveness, I added a "made_for" tristate variable to struct
> revision_t.  If you manufacture a revision by hand, you have to set
> this to either made_for_workspace or made_for_database, and the
> revision will be unacceptable to whichever consumer (the workspace or
> the database) it is not made for.  [New code should be using
> make_revision / make_revision_for_workspace; I'm aware that you can't
> do everything with those, but the intent is to change that over on
> .noconflict.  I might also turn them into real constructors.]

We went back and forth about this on IRC some today... I'm still not
sure what exactly this gives us.  My understanding is that there are
basically two differences between database revisions, and workspace
revisions:
  -- workspace revisions may contain nonsense, like fake manifest ids
  -- workspace revisions may not actually represent anything useful
     (for instance, they may be missing file content changes)

These are important properties, that one has to keep in mind while
coding, and tool support to help us do that is good... but I don't
understand ATM what this is helping.  The first property is already
checked where relevant (i.e., the database won't accept nonsense), and
adding another check, also at runtime only, doesn't seem to improve
matters much?  The second one maybe is improved by having functions
that take one sort of revision or the other, and I like the idea of
make_revision_for_workspace as a function name regardless, but I don't
know that I even understand what we as programmers need, to tell if
this sort of runtime tracking is it.  (We already have to think about
the difference between shape-only and real rosters, node_id
namespaces, and so on.)  So maybe what we need is a better
articulation of what this tri-state helps with?

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco