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

[Zack Weinberg]

On 9/6/06, Nathaniel Smith <address@hidden> wrote:
> On Tue, Sep 05, 2006 at 02:11:44PM -0700, Zack Weinberg wrote:
> > As a consequence of this change, the "new_manifest" field of the
> > revision in _MTN/revision is now *always* fake.
...
> [A non-fake new_manifest field]'s not the cheapest thing in the world to
> calculate, and never useful.  (Generally, it's the hash of some manifest
> quite different from the one the workspace actually represents.)

Yup.  I was going to mention this as another factor, but I forgot.
I'm going to take this as concurrence with the general idea of having
the new_manifest be fake in a workspace revision?

Tangentially, I suspect that some of the messing with rosters that
various workspace-manipulation commands do is unnecessary (see
work.cc::perform_* -- I'm not sure how to code them differently, but
there does seem to be an awful lot of extra work going on there)

> > great defensiveness, I added a "made_for" tristate variable to struct
> > revision_t.
...
> We went back and forth about this on IRC some today... I'm still not
> sure what exactly this gives us.

To be honest, I'm not sure it gets us much myself.  The main
additional benefit, above the checks the database does already, is
that we can prevent writing database-ready revisions to the workspace.
This seems to me like a desirable check, but I can't quite articulate
*why*.  Maybe just because we want to avoid doing the extra work that
it takes to construct a database-ready revision...?

If I could tell the difference between a fake ID and a real one after
the fact, I think the tristate could go away.  This would also patch
up the hole where read_revision() can't tell whether it's reading a
database or a workspace revision, and thus
packet_db_writer::consume_revision_data() [I'm not 100% sure that's
what it's called] has to assume that it is being fed a serialized
database revision.  This is mostly harmless because of the later
database sanity checks, but still makes me uncomfortable.

> (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?

... I concur, but I don't think I know enough to work out that
articulation; I could try, but I think there's more useful ways for me
to spend my time...?

zw