Versioning of external extensions?

Jason Harris jason at jasonfharris.com
Fri May 14 00:12:57 UTC 2010


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.

Reported as issue:2189

I use the above to count the number of changesets which are incoming, and it started failing after I made the simple switch over to if (stderr matches /^abort:/ OR exit status != 0  ==>> hg failed.

So in the face of such things would 

 if (stderr matches /^abort:/ OR (exit status != 0 && notEmpty(stderr))
     hg failed
 else
     hg succeeded

Be reasonable?  Ie anyone know of critical bugs which don't have an error message?  Or maybe I should treat the code 1 as a special case and use the following heuristic:

 if (stderr matches /^abort:/ OR (exit status == 1 && notEmpty(stderr)) OR (exit status != 1 && exit status != 0)
     hg failed
 else
     hg succeeded


> But this is all hand-wavey fuzzy heuristics.  Your real question was
> 
>>  It would be nice to have a recommended list of error codes and then GUI tools can
>> respond appropriately. (Maybe such a list already exists and I just don't know about
>> it, it hasn't been published / put on the wiki somewhere?)
> 
> and, AFAIK, such a list does not exist.  (I presume you searched the wiki?)

Yep. I looked around.

Cheers,
  Jason


More information about the Mercurial mailing list