Re: [Monotone-devel] ikiwiki and monotone

[Nathaniel Smith]

On Wed, Oct 11, 2006 at 12:36:10PM +1000, Brian May wrote:
> >>>>> "Brian" == Brian May <address@hidden> writes:
> 
>     Brian> Hello, Anyone considered adding monotone support to
>     Brian> ikiwiki?
> 
>     Brian> http://ikiwiki.kitenet.net/
> 
> No response?
> 
> Nobody interested?

Well, Dan (who just replied) has been raving about it on IRC for the
last few days since you posted :-).

>     Brian> * How do you determine the creation date/time of a file? Or
>     Brian> the data/time of the first revision would probably be
>     Brian> sufficient too.
> 
> Is there a better way?
> 
> 1. base_id = `mtn automate get_base_revision_id`
> 2. output= `mtn get_roster $base_id`
> 3. birth_id= `scan $output for birth revision id for $file`
> 4. output= `mtn automate certs $birth_id`
> 5. scan output for date certificates.
> 6. decide what to do if multiple date certificates appear.
> 
> Steps 3 and 5 appear non-trivial and inefficient.

That is currently the best way.  It is kind of a terrible way, I
agree, though more because 'get_roster' is a debugging interface that
can and probably will get torn out or changed at any point.

To avoid this, we should add an "automate get_birth_revision" command,
or something like that.  We recently added "get_corresponding_path"
and "get_content_changed" commands to expose similar bits of roster
information; it would be trivial to do the same for the birth
revision.  (Tangent: why are we putting "get_" at the beginning of all
of these commands?  Are there any automate commands that do not
provide information?)  Patches accepted :-).

So you'd end up doing

1. base_id = `mtn automate get_base_revision_id`
2. birth_id = `mtn automate get_birth_revision $base_id $file`
3. certs = `mtn automate certs $birth_id`
4. parse certs string, come up with some sort of date from it

This is about as efficient as anything you can do.  The parsing bit is
somewhat annoying -- unfortunately, I don't think that anyone has
actually written a basic_io parser for perl yet.  It's pretty
straightforward to do (certainly easier than writing your average
library binding ;-)), and if you did it then we could distribute it
and no-one would ever have to do it again, but there it is.  A useful
thing to look at might be the python module that's part of the new
viewmtn that Grahame just posted a link to today -- not perl, but
perhaps similar enough in spirit.

The bit about having to pick a date if there are several date certs
(or potentially fail if there is no date cert) is unfortunate, but
basically unavoidable.  What you get is what monotone stores, if you
want something else that monotone doesn't store, then you have to
figure out what the best way to approximate it is in your particular
situation.  Since monotone doesn't know your situation, it can't
really tell what the best way to guess would be.

Picking either an arbitrary date, or the earliest one listed, would
both probably work here.

> Maybe if I could replace the above with the following steps :
> 
> 1. base_id = `mtn automate get_base_revision_id`
> 2. birth_id= `mtn get_roster $base_id $file birth`
> 3. date=`mtn automate certs $birth_id date | head 1`

If you have a basic_io parser, it's easy to extract arbitrary
information from both "automate certs" and every other place monotone
needs structured information.  But adding a third argument to "certs"
only works for one particular piece of information (the cert value),
and it introduces ambiguities (like what if there _are_ two date
certs, should monotone be spitting out their values one after another?
How could this be distinguished from a cert that just happens to have
two lines in it?).

> (I note mtn automate certs returns a signature "ok" field - does this
> mean it will list signatures that are not OK?)

It will list signatures that are not ok, yes -- all "automate"
commands have reasonably comprehensive documentation, see
  http://venge.net/monotone/docs/Automation.html

Hope that helps,
-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein