Re: [Monotone-devel] A few thoughts...

[Tom Tromey]

>>>>> "Ori" == Ori Berger <address@hidden> writes:

Ori> Issue Tracking; It's probably beyond the scope intended for monotone
Ori> now, but every version control system eventually needs to integrate
Ori> with an issue tracking system. The right kind of hooks in the version
Ori> control system will make it much easier to integrate. I don't think I
Ori> know of an issue tracking tool that works well with CVS's branching. I
Ori> don't know what the right hooks are, though.

I can think of one way.  Suppose you sign versions with test results.
Then you can reduce this to a testing problem -- link the test to the
PR, and you can inspect a given manifest to see if it has been signed
as passing whatever test(s) (hence PRs) you are interested in.  A
component of this idea is a tinderbox-like program that continually
checks out, builds, tests, and then posts a new certificate with the
results.

There's still a question of how to turn test results into something
that can be used as a "monotone update" sort key.  I suppose at the
very least you could make up something outside of monotone.

Of course, in reality you usually don't end up with a test case for
every PR.  You could sign a version when a bug is fixed (and do this
on any branch where it is fixed), but this won't automatically
propagate to new revisions.  I suppose you could run queries against
the database, looking for the first ancestor which has either a "bug N
fixed" certificate or, conversely, a "bug N regressed" one (but this
isn't necessarily well defined).  Then you could hook up the bug
tracking system to automatically add a "bug N regressed" certificate
to the revision against which the bug is verified.

With this approach you could easily answer questions like "what bugs
were fixed since the last release?" or "what bug-fixing patches on the
release branch were not applied to the trunk?".

Ori> Central repository; by that, I mean to let several users share the
Ori> same store. It might even work today, as sqlite has support for
Ori> simultaneous access to a database (assuming proper remote locking
Ori> semantics, which unfortunately older NFS versions lack). But it's
Ori> something that is easy to break.

It seems to me that you could always change the storage implementation
to use postgres or something like that.  I haven't delved into the
schema, so I can't say with confidence that monotone would cope with
this gracefully...

Tom