Re: [Monotone-devel] project_t , and preparing for projects / policy branches

[Nathaniel J. Smith]

On Sat, Jan 13, 2007 at 01:58:05PM -0600, Timothy Brownawell wrote:
> I've been reorganizing things somewhat to try to prepare for
> implementing a concept of a "project" that we'll need for the policy
> work.

Huzzah.

It's going to be weird at the summit, trying to seriously sit down and
hack this stuff out, without you there.  Think you'll be around on IRC
at least or so?

> So far, this mostly means that I've added a project.{cc,hh} with a
> project_t class, and that things that make / query certs (and this
> includes things that ask about branches) have to go through this.
> Anything dealing with keys should also end up going through here, but I
> haven't done that part yet.

Better factoring?  Shocking! :-)

> There is currently a single project, accessed by app.get_project(). I'm
> thinking that later this will become the default project, which is
> whatever is specified either in _MTN/options or on the command line. We
> can also have app.get_project(string) for operations like netsync or
> automate (stdio) that want to be able to look at multiple projects.

Makes sense.  We might want to consider making the project something
that gets passed around directly, as well, instead of being global
state, if we want one process to be able to work with multiple
projects.  I guess this would fit into the general trend of trying to
split things out of the app_state blob, and might or might not be
sensible to mix in with other changes now.

> The database class had several get_revision_certs() functions. Most uses
> of these (the exception being some code that looked like it was for
> migration) now go through project_t. The functions in project_t aren't
> (all) just wrappers, they have names based more on how the functions the
> wrap were used, and are changed to fit those uses better. (For example,
> the "get all certs of type foo" variant became "project_t::get_tags()",
> because that's all it was used for.)

Huh, didn't we also have "get all branch certs"?  And I guess the
selector stuff is all inside database.cc, so never mind that...

> Also, the mentioned get_tags() returns a set of new "tag" objects. The
> code that used it wanted to know the key used for signing the tag, but I
> don't think it's at all certain that tags will remain implemented as
> certs (putting them in the policy branch should allow them to become
> more interesting). So, just returning a set of certs probably wouldn't
> be good.

Yeah, tags are an interesting question.  We should probably even
consider simply throwing them out altogether -- the only thing I can
think that's actually different between tags and (what monotone calls)
branches is that if you do
  mtn co -rt:foo
you don't want monotone to guess that the workspace should have its
default branch set to "foo", but rather to whatever "real branch" the
revision is in (if there is one).

> One other change is that there's an outdated_indicator.{cc,hh} that's
> used by the database cert query functions to let their users find out
> when the returned info might be outdated. Currently, this is only really
> used by project_t::get_branch_heads(), with the result that calling
> 'heads' repeatedly for the same branch (say, through automate stdio) is
> very fast after the first time. I don't really know if we want to keep
> this, it's mostly there just because it occurred to me while I was
> messing around trying to figure out how to get started on this
> "(re)organize things to prepare for having a 'project' concept" thing.

This is technically sort-of incorrect, isn't it, because in principle
the trust hooks might return different values the first and second
time they are called?  Not that anyone is likely to complain within a
single monotone instance, though in the long run one of the things
that having more control over trust will give us is the ability to
cache such decisions on _disk_.  We will almost certainly need to
eventually cache head sets on disk in order to scale.

-- Nathaniel