Closed Bug 723638 Opened 12 years ago Closed 12 years ago

Mercurial 2.1 returns 1 if nothing was pulled, in which case client.py doesn't succeed

Categories

(MailNews Core :: Build Config, defect)

Product:
MailNews Core
Component:
Build Config
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: fredbezies, Unassigned)

Details

Very recent problem. For a few hours, when I type python2 client.py checkout --verbose, I got this message :

The exception was:
subprocess.CalledProcessError: Command '['/usr/bin/hg', 'pull', '-R', './.']' returned non-zero exit status 1

Traceback (most recent call last):
  File "client.py", line 609, in <module>
    do_hg_pull('.', options.comm_repo, options.hg, options.comm_rev)
  File "client.py", line 330, in do_hg_pull
    check_call_noisy(cmd, retryMax=options.retries)
  File "client.py", line 158, in check_call_noisy
    raise Exception("Command '%s' failed %d time(s). Giving up." % (cmd, retryMax + 1))
Exception: Command '['/usr/bin/hg', 'pull', '-R', './.']' failed 2 time(s). Giving up.

Of course, client.py python script was working perfectly a few hours ago.
Does running:

hg pull -R ./.

work for you when run manually? it sounds like you're having problems pulling from hg itself, but before we stuff this over to ServerOps I want to be sure.
Product: Thunderbird → MailNews Core
QA Contact: build-config → build-config
Looks like it work.

[fred@fredo-arch src]$ hg pull -R ./.
pulling from http://hg.mozilla.org/comm-central/
searching for changes
aucun changement trouvé

I'm using a french translated mercurial, last sentence meaning : no changes found.
can you try client.py again then?
Good this just came up, I had the same issue on the calendar builder. I might know whats happening.  Try this:

hg pull -R ./.
echo $? 

You'll see that since there are no changes, hg returns exit code 1, which client.py thinks is an error.
Happens for me with Mercurial 1.9.1 on windows
Actually, its Mercurial 2.1!
(In reply to Philipp Kewisch [:Fallen] from comment #4)
> Good this just came up, I had the same issue on the calendar builder. I
> might know whats happening.  Try this:
> 
> hg pull -R ./.
> echo $? 
> 
> You'll see that since there are no changes, hg returns exit code 1, which
> client.py thinks is an error.

You got it. A bug in client.py ?
(In reply to Frederic Bezies from comment #7)
> (In reply to Philipp Kewisch [:Fallen] from comment #4)
> > Good this just came up, I had the same issue on the calendar builder. I
> > might know whats happening.  Try this:
> > 
> > hg pull -R ./.
> > echo $? 
> > 
> > You'll see that since there are no changes, hg returns exit code 1, which
> > client.py thinks is an error.
> 
> You got it. A bug in client.py ?

Actually, imo this is a bug in hg, however it was intentionally changed to do this afaict.

HG is returning what is really an error code (`1`) when it has no changes. They apparently have had this behavior for a while with hg incoming which was determined as intended, so I suspect this is to match  that behavior.

It means that we will be fixing client.py to work around this :/ No ETA yet, but we will plan on getting it into all current repos when fixed.
Temporary workaround: Install Mercurial 2.0.2, where it still returns 0.
(In reply to Philipp Kewisch [:Fallen] from comment #9)
> Temporary workaround: Install Mercurial 2.0.2, where it still returns 0.

Downgraded mercurial. Hope this problem with mercurial get fixed soon :D
(In reply to Frederic Bezies from comment #10)
> (In reply to Philipp Kewisch [:Fallen] from comment #9)
> > Temporary workaround: Install Mercurial 2.0.2, where it still returns 0.
> 
> Downgraded mercurial. Hope this problem with mercurial get fixed soon :D

From the looks of it, it was intentional on their side, so we'll need to fix it in our script here.

Sad, but true.
Yesterday I've updated to Mercurial 2.1 via Macports and now I'm also seeing this error. And I can't downgrade Mercurial, because there is only version 2.1 available on MacPorts now.
https://bugzilla.mozilla.org/show_bug.cgi?id=725362#c5

This would not matter for me if there were only this error, but it also doesn't update my tree. It doesn't pull the latest changes.
OS: Linux → All
Hardware: x86_64 → All
(In reply to Nomis101 from comment #12)
> Yesterday I've updated to Mercurial 2.1 via Macports and now I'm also seeing
> this error. And I can't downgrade Mercurial, because there is only version
> 2.1 available on MacPorts now.
> https://bugzilla.mozilla.org/show_bug.cgi?id=725362#c5
> 
> This would not matter for me if there were only this error, but it also
> doesn't update my tree. It doesn't pull the latest changes.

Workaround is to manually pull, alternative is for me to say "patches accepted".

Sadly I just don't have time this week to do this patch, but would review any patch here asap.
Summary: client.py cannot get source code grabbed. → Mercurial 2.1 returns 1 if nothing was pulled, in which case client.py doesn't succeed
(In reply to Justin Wood (:Callek) from comment #13)
> Workaround is to manually pull, alternative is for me to say "patches
> accepted".
> 
> Sadly I just don't have time this week to do this patch, but would review
> any patch here asap.

What is needed here to fix this?
(In reply to Nomis101 from comment #14)
> (In reply to Justin Wood (:Callek) from comment #13)
> > Workaround is to manually pull, alternative is for me to say "patches
> > accepted".
> > 
> > Sadly I just don't have time this week to do this patch, but would review
> > any patch here asap.
> 
> What is needed here to fix this?

Roughly Speaking unravel most of the command runs here to check return code and in the "legit" cases treat `1` as ok, and don't exit client.py/abort.
OK, I see. I'm willing to play arround with that and, in the best case, fix it and make a patch. But I can't promise anything...
Ah, now I realize this is the problem I'm seeing recently on my desktop machine.

Did earlier Mercurial versions return 1 in cases that are legit errors? If yes, we probably need some kind of version detection in client.py to deal with that - if no, it should be easy to take >1 as failure and <=1 as success.
(Bah, a return code other than 0 for a non-failure is violating usual standards of unix-like systems, but I guess hg just doesn't care about that.)
I'll set this to WONTFIX, as Mercurial has reverted this in 2.1.1 and that version works well with client.py again.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.