Versioning of external extensions?

[Jason Harris]

On May 14, 2010, at 2:37 AM, Matt Mackall wrote:

> On Fri, 2010-05-14 at 02:12 +0200, Jason Harris wrote:
>> On May 12, 2010, at 10:20 PM, Greg Ward wrote:
>> 
>>> On Wed, May 12, 2010 at 3:49 AM, Jason Harris <jason at jasonfharris.com> wrote:
>>>> Well that stands to reason that GUI programs shouldn't have a "cow" when something doesn't work. In order to not have a "cow" is there a recommended list of error codes when we should have a "cow"?
>>> 
>>> Unfortunately, Mercurial is a bit inconsistent with process return
>>> codes.  You might say it's downright mercurial in that regard.  ;-)
>>> *Generally* exit status 0 means success and non-zero means failure,
>>> but there are some failure cases where it exits with 0.  These are
>>> bugs and should be reported as such.  I don't know of any success
>>> cases where it exits with non-zero; if they exist, they are bugs and
>>> should also be reported.
>>> 
>>>> Ie right now the missing extension warning / error gets written to stderr by Mercurial, but the error code returned by Mercurial I think is 0 from memory.
>>> 
>>> Right, because it's a *warning*.  Many operations can still succeed
>>> perfectly well even if extension X did not successfully load.
>>> 
>>>> However I have seen other error codes returned, and errors with the text "Abort!" in
>>>> them.
>>> 
>>> Most of the time "abort: " goes along with a non-zero exit status, and
>>> indicates a fatal error.  If you want to be really safe, I would say
>>> 
>>> if (stderr matches /^abort:/ OR exit status != 0)
>>>   hg failed
>>> else
>>>   hg succeeded
>>> 
>>> where that hypothetical regex match means "if any line of stderr
>>> starts with "abort:".
>> 
>> Yeah I just had a play with switching this over and pretty quickly found the following problem (this happens in 1.4.3 as well)
>> 
>> [quicksilver:~] $ hg clone http://selenic.com/repo/hello
>> destination directory: hello
>> requesting all changes
>> adding changesets
>> adding manifests
>> adding file changes
>> added 2 changesets with 2 changes to 2 files
>> updating to branch default
>> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
>> [quicksilver:~] $ cd hello
>> [quicksilver:~/hello] $ hg incoming --config defaults.incoming= --noninteractive --quiet --template "-" http://selenic.com/repo/hello
>> [quicksilver:~/hello] $ echo $?
>> 1
>> [quicksilver:~/hello] $ hg version -q
>> Mercurial Distributed SCM (version 1.5+20100307)
>> [quicksilver:~/hello] $ 
>> 
>> As can be seen the exit code of the hg incoming is 1. it should be 0.
> 
> That is in fact long-standing and expected behavior. It lets scripts do:
> 
> hg incoming > /dev/null || echo "Nothing to pull"
> 
> There's plenty of precedence for this sort of thing, see grep for
> instance. Non-zero exit codes != failure.
> 
> As I've said for years now, what's needed is for someone to audit the
> return codes, document them, and fix the ones that don't make sense.

So any improvements then on what I put down before as to what a GUI should consider a "real" error as opposed to a warning?

The best case would be that there is a consistent set of codes and a simple algorithm to decide if something is a real error; and the worst case would be that the error codes mean different things for each command, and you need to know a matrix of commands and error codes to determine when something is a real error...

Cheers,
  Jas