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

[Thomas Keller]

Stephen Leake schrieb:
> Thomas Keller <address@hidden> writes:
> > Stephen Leake schrieb:
> > > Which means we probably should use two digits for the minor number;
> > > we'll probably have more than 10 backward-compatible changes before
> > > the next incompatible change.
> > Ok, this is another thing which should be ruled: in my opinion what
> > follows on x.9 is x.10 aso. In guitone I split up on "." and compare the
> > major and the minor numbers separately.
>
> Well, that works, but it's clearer if we go from x.09 to x.10. 

I don't like the idea of padding zeros to these numbers. The thing is 
that it merely serves the interface developer in whose environment it is 
rather hard to do "7.2".split(".")[1].toInt() (pseudo code) and compare 
that value then further.

Actually, I don't like the idea of changing anything wrt interface 
numbering - if people really have a problem with it, then I'm on Thomas 
Moschny's side and would rather vote for stripping any versioning number 
off the code and replace it by magic capabilities strings (though this 
will have its very own set of problems I believe).

> > > Another nit: you have a C for inventory for 7.0. That change was the
> > > addition of --no-ignored, --no-unknown, --no-unchanged,
> > > --no-corresponding-renames. That was backward-compatible, so it should
> > > be B.
> > This is, like the --depth thing, debateable. I fully agree that the new
> > options are backwards-compatible, however, the change that it no longer
> > recurses into ignored directories which happened in the same release was
> > for me backwards-incompatible, because for a given fixed input the
> > output, i.e. the amount of nodes returned, changed significantly.
>
> Ok. I just viewed that as fixing a bug. Not a big deal.

Whether or not we're doing the cap.-bits thing it would surely be useful 
to define once and for all what should actually be an "incompatible 
change". I haven't heard much of the other voices yet on this issue.

> > > In practice, you can just check the mtn version, since the automate
> > > interface version changes in sync with that.
> > Not always. In the past there have been quite a few releases where
> > nothing had been changed, so interface_version kept constant. This is
> > also wanted; if you develop a tool that relies on a certain interface
> > version like 8.3, you should be able to safely deploy that with any
> > monotone release with an interface version 8.3 <= x < 9.0. 
>
> Hmm. I guess you are implying that this tool should complain that it
> might not work on a version that is 9.0 or greater. Ok, that makes
> sense. But it is quite likely overconservative. For example, how many
> tools actually _relied_ on inventory recursing into ignored
> directories? 

I have no idea if any other tools beside DVC and guitone actually use 
inventory nowadays heavily, so I have no idea if they used this 
"feature" or not. But certainly, other incompatible changes in the past 
would made this exact version parsing needed.

guitone is coded very conservative in this case. I rather throw an 
"unsupported version" message at the user beforehand than letting him 
find some obscure bug / crash because a format change triggered an 
invariant in my code, f.e.

> But you have ignored my point that it is just as likely that a tool
> that works on mtn 0.38 might not work on mtn version 0.40.
>
> 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).

> Although it may be that there are ways to effect some of the
> non-automate commands via automate. You have mentioned that your tool
> does not use 'mtn commit', but rather some combination of automate
> commands. It would be useful to document that combination in the mtn
> user guide.

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

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.

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

Thomas.

--
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature