[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Keller
Subject: Re: [Monotone-devel] interface version / command matrix
Date: Sat, 29 Mar 2008 13:16:06 +0100
User-agent: Thunderbird (Macintosh/20080213)

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

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 ;)


GPG-Key 0x160D1092 | address@hidden |
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:

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]