Re: [Monotone-devel] interface version / command matrix

[Stephen Leake]

Thomas Keller <address@hidden> writes:

>> Unless the tool uses _only_ automate commands, it _must_ check the mtn
>> version number. I don't think automate is powerful enough for that.
>> Nor do I think it needs to be.
>
> That is the contract interface_version guarantees. guitone _solely_
> depends on automate currently (ok, despite one very little use case
> where I use mtn pubkey - but this is on my TODO list, i.e. I plan to
> implement mtn automate get_public_key some time).
>
>>> No code changes would need to be done on the client's side to
>>> support a new monotone release which does no or just a minor changes
>>> to the interface.
>> I define "the interface" to include the mtn commands, as well as the
>> mtn automate commands.
>
> For me its the other way around. I program the tool against the
> automation interface by purpose, because this interface is the only
> one which guarantees me at least some kind of stability. Sure, there
> are still a lot of missing commands and functionality, the problem of
> mediocre error (plain string) reporting, no ticker support, aso. - but
> this is nothing which cannot be addressed in the future.
>
> The "big" plan for me certainly is making automate feature-complete
> (with the exclusion of some rarely needed commands like mtn crash ;),
> because only when its feature-complete it can actually be useful for
> everybody. And people can start using it for even more obscure things,
> like providing new command line frontends which has already been done
> in the past (see the mtn_automate lua function).

That makes sense.

However, the more features the automate interface supports, the more
likely it is that some individual feature will suffer an incompatible
change, and the major version will increase, incorrectly labeling all
features as incompatible.

So a keyword list is the right way to go.

> In the development version of guitone I do the following to "commit":
>
> * query automate get_option branch and automate keys (the latter for
> finding out the private keys which can be used to sign the certs later
> on), optionally allow the user to override these values. the date cert
> will be later hard-coded to the current datetime, the author can be
> explicitely overwritten, otherwise I'll just use the value I got from
> mtn automate keys.
> * call automate get_current_revision to receive an (optionally
> restricted) changeset on the current workspace
> * parse this revision text and look for file patches and file adds
> * iterate over these findings and call automate put_file on each of
> them while reading the contents of the files from disk)
> * writing the revision text to the database via automate put_revision
> * write the supplied certs to the database via automate cert
> * after the revision was committed successfully, I write any new
> options to _MTN/options and also write out a clean (empty) revision to
> _MTN/revision

Thanks.

> The only thing what is missing currently (but this also applies to the
> usage of mtn commit) is a sane way to ask the user for passphrase
> input. But again, this is also something which is on my longish TODO
> list -
> finding a sane way to supply the passphrase to automate.

For me and Emacs DVC, I think ssh-agent is the best solution to that.
That's on my todo list (ssh-agent doesn't work with mtn on Win32, at
least not generally).

> Feel free to add this into the monotone documentation - your English
> is probably better anyways ;)

Ok.  I'll add the similar list for merge once I figure it out.

--
-- Stephe