Re: [Monotone-devel] monotone evaluation in commercial project [long]

[Nathaniel Smith]

On Wed, Apr 13, 2005 at 12:01:32PM +0200, rghetta wrote:
> Yes, I was referring to commit comments, but this applies also to 
> testcerts (or any other custom cert, for that matter).
> Perhaps the question could be better rephrased as "which changeset were 
> commited this week?".

I think this isn't actually the question you want to ask.  "Which
changesets are new since the last time I asked" is better, because it
depends only on the ancestry graph, not on dates, which are
unreliable.  Remember, there's no guarantee that time will move
forward, since we don't have a central server with a central
clock to create timestamps.  (In fact, there's no guarantee even if we
did, since people can rewind their clocks, but you can at least
pretend more easily.)  Some scenarios:
  - Joe's clock is off, so he marks a commit or two as occurring in
    1983, before noticing and fixing the clock.  These commits never
    show up in any of your reports.
  - Susan commits some changes, then goes out of town for a week.
    When she gets back, she realizes that she forgot to push her
    changes out, and does so (hoping her manager won't notice).  These
    changes didn't show up in last week's report, since they were still
    sitting in Susan's local database; they won't show up in this
    week's report, since they are dated last week.

So, you're better off just sticking to the ancestry graph -- this
is much simpler and more robust.  Several of the new automate commands
were added to support exactly this scenario; the
contrib/ciabot_monotone.py script is a working example of doing this
kind of change detection.

> The real problem is getting that information out of monotone without 
> having to parse unformatted data.
> At the sql level this is trivial, but the cert value is encoded, as you 
> pointed out.
> Besides, if I understand correctly monotone operation, the database 
> could contain "untrusted" revisions, and only by checking keys and 
> certificates you can filter them out.
> IMHO, this pretty much rules out direct database access, leaving only 
> the monotone standard commands.

Yeah, we do try to discourage direct database access, for the reasons
mentioned.  (Plus, it's not guaranteed to stay at all compatible
between releases.)

> But with these even getting the changeset commited this week is not 
> easy: I haven't found a way to get it other than the log command, and 
> that not that easy to parse and requires a working copy (why ?)

Hmm, if it does, that's a bug.  But I don't think it does, if you give
it a revision to start with?  (Otherwise it assumes you want to start
with whatever revision you have checked out.)

> Besides, I was unable to obtain a log starting point using a date 
> selector (probably my mistake) and anyway you can limit on the number of 
> entries, not on the date/author/whatever.

Right, for reasons above.

> While having all the listing command understand a range could answer 
> this simple case, more advanced queries aren't that simple.  As an 
> example: "Which files were changed more than 25 times last month ?" or 
> "What's the mean time beetween successive changes of a file ?" or even 
> "Who's the most/least prolific committer ?"
> I do not see a way to answer these questions without parsing the entire 
> history and dumping into another database for queries.
> Obviously monotone is a SCM, not a reporting tool, but most of the 
> informations needed to answer these questions are already in sqlite 
> tables as columns (ok, file informations are not), thus seems such a 
> waste not having some form of querying interface.

These sound like interesting questions.  I think the best approach
would be to extend the "automate" interface to be more useful here.
(We very much follow the "implement it when someone actually needs it"
theory of design, on the grounds that this way you're at least
implementing useful things...)  One major lack in "automate" right now
is a way to get certs out... if you have any ideas on what operations
should be added to automate, what the data format should look like,
or even patches to implement previous, etc., it would be greatly
appreciated.

-- Nathaniel

-- 
Damn the Solar System.  Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better one myself.
  -- Lord Jeffrey