Re: [Monotone-devel] ikiwiki and monotone

[Brian May]

>>>>> "Nathaniel" == Nathaniel Smith <address@hidden> writes:

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

Maybe I was just a little bit too impatient ;-)

Strangely, I got Dan's reply he CCed me, but didn't get a copy of the
message via the mailing list.

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

Yes, the fact it is listed under "debug" made me kind of nervous too.

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

Will there ever be commands that do other things in the future?

My only complaint with naming is:

mtn automate erase_ancestors

To me that sounds like the operation will erase the ancestors of the
given revision. Even though this does sound like a dangerous operation
;-).

While I am not awake enough to understand exactly what is does right now, I 
suspect
it is a read-only operation. get_erase_ancestors might be better.

    Nathaniel> So you'd end up doing

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

Sounds good.

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

If I get some spare time I might have a look. I haven't written much
python, but I am confident I will be able to read it ;-).

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

Yes. Oh the fun of incompatible models ;-).

Having said that, I really like monotone's model so far.

Another issue will be that ikiwiki expects a 1d array for log
entries. I see mtn log already does something similar though, so I
suspect it will be easy to work something out.

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

I suspect the earliest date might be best for this purpose.
-- 
Brian May <address@hidden>