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

[Timothy Brownawell]

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.

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.

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.

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.)

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.

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.

-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net