Versioning of external extensions?

[Matt Mackall]

On Fri, 2010-05-14 at 02:45 +0200, Jason Harris wrote:
> 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?

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.