Versioning of external extensions?

[Matt Mackall]

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.

-- 
Mathematics is the supreme nostalgia of our time.