[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] ikiwiki and monotone
From: |
Brian May |
Subject: |
Re: [Monotone-devel] ikiwiki and monotone |
Date: |
Wed, 11 Oct 2006 18:31:35 +1000 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) |
>>>>> "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>
- Re: [Monotone-devel] Re: ikiwiki and monotone, (continued)
- Re: [Monotone-devel] Re: ikiwiki and monotone, Brian May, 2006/10/12
- Re: [Monotone-devel] ikiwiki and monotone, Brian May, 2006/10/12
- Re: [Monotone-devel] ikiwiki and monotone, Chad Walstrom, 2006/10/13
- [Monotone-devel] Re: ikiwiki and monotone, Bruce Stephens, 2006/10/13
- Re: [Monotone-devel] Re: ikiwiki and monotone, Nathaniel Smith, 2006/10/14
Re: [Monotone-devel] ikiwiki and monotone, Nathaniel Smith, 2006/10/11
Re: [Monotone-devel] ikiwiki and monotone, Daniel Carosone, 2006/10/11
Re: [Monotone-devel] ikiwiki and monotone, Nathaniel Smith, 2006/10/11
Re: [Monotone-devel] ikiwiki and monotone, Brian May, 2006/10/12
Re: [Monotone-devel] ikiwiki and monotone, Václav Haisman, 2006/10/11