[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 2.0.0.12 (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
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
- [Monotone-devel] interface version / command matrix, Thomas Keller, 2008/03/27
- Re: [Monotone-devel] interface version / command matrix, Thomas Keller, 2008/03/27
- Re: [Monotone-devel] interface version / command matrix, Stephen Leake, 2008/03/28
- Re: [Monotone-devel] interface version / command matrix, Stephen Leake, 2008/03/28
- Re: [Monotone-devel] interface version / command matrix,
Thomas Keller <=
- Re: [Monotone-devel] interface version / command matrix, Thomas Keller, 2008/03/29
- Re: [Monotone-devel] interface version / command matrix, Thomas Moschny, 2008/03/29
- Re: [Monotone-devel] interface version / command matrix, Stephen Leake, 2008/03/30
- Re: [Monotone-devel] interface version / command matrix, Daniel Atallah, 2008/03/30
- Re: [Monotone-devel] interface version / command matrix, Nuno Lucas, 2008/03/30
Re: [Monotone-devel] interface version / command matrix, Thomas Moschny, 2008/03/28