Augie Fackler <augie@google.com> [Tue, 07 Mar 2017 13:24:24 -0500] rev 30888
pycompat: verify sys.argv exists before forwarding it (issue5493)
ISAPI_WSGI doesn't set up sys.argv, so we have to look for the
attribute before assuming it exists.
Augie Fackler <raf@durin42.com> [Thu, 02 Mar 2017 20:19:45 -0500] rev 30887
Added signature for changeset 25703b624d27
Augie Fackler <raf@durin42.com> [Thu, 02 Mar 2017 20:19:43 -0500] rev 30886
Added tag 4.1.1 for changeset 25703b624d27
Augie Fackler <raf@durin42.com> [Thu, 02 Mar 2017 20:07:35 -0500] rev 30885
merge with i18n
Wagner Bruna <wbruna@softwareexpress.com.br> [Thu, 02 Mar 2017 11:08:20 -0300] rev 30884
i18n-pt_BR: synchronized with 7074589cf22a
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 01 Mar 2017 16:43:22 +0900] rev 30883
i18n-ja: synchronized with 7074589cf22a
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Feb 2017 12:48:50 +0900] rev 30882
worker: flush messages written by child processes before exit
I found some child outputs were lost while testing the previous patch. Since
os._exit() does nothing special, we need to do that explicitly.
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Feb 2017 12:33:37 +0900] rev 30881
worker: add basic test to ensure child processes are managed well
This should catch the bug fixed by "worker: ignore meaningless exit status
indication returned by os.waitpid()."
Before, worker.py was untested since test repositories are relatively small.
eloimorlaas <eloimorlaas@fb.com> [Thu, 23 Feb 2017 11:23:17 -0800] rev 30880
record: update help to describe ui.interface
hg help record was not accurate if using another interface than the text one
Rishabh Madan <rishabhmadan96@gmail.com> [Sat, 25 Feb 2017 16:57:21 +0530] rev 30879
ui: replace obsolete default-push with default:pushurl (issue5485)
Default-push has been deprecated in favour of default:pushurl. But "hg clone" still
inserts this in every hgrc file it creates. This patch updates the message by replacing
default-push with default:pushurl and also makes the necessary changes to test files.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 25 Feb 2017 01:07:52 +0900] rev 30878
worker: ignore meaningless exit status indication returned by os.waitpid()
Before this patch, worker implementation assumes that os.waitpid()
with os.WNOHANG returns '(0, 0)' for still running child process. This
is explicitly specified as below in Python API document.
os.WNOHANG
The option for waitpid() to return immediately if no child
process status is available immediately. The function returns
(0, 0) in this case.
On the other hand, POSIX specification doesn't define the "stat_loc"
value returned by waitpid() with WNOHANG for such child process.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/waitpid.html
CPython implementation for os.waitpid() on POSIX doesn't take any care
of this gap, and this may cause unexpected "exit status indication"
even on POSIX conformance platform.
For example, os.waitpid() with os.WNOHANG returns non-zero "exit
status indication" on FreeBSD. This implies os.kill() with own pid or
sys.exit() with non-zero exit code, even if no child process fails.
To ignore meaningless exit status indication returned by os.waitpid(),
this patch skips subsequent steps forcibly, if os.waitpid() returns 0
as pid.
This patch also arranges examination of 'p' value for readability.
FYI, there are some issues below about this behavior reported for
CPython.
https://bugs.python.org/issue21791
https://bugs.python.org/issue27808
Siddharth Agarwal <sid0@fb.com> [Mon, 13 Feb 2017 11:43:12 -0800] rev 30877
bundle2: fix assertion that 'compression' hasn't been set
`n.lower()` will return `compression`, not `Compression`.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:20:58 +0100] rev 30876
wireproto: properly report server Abort during 'getbundle'
Previously Abort raised during 'getbundle' call poorly reported (HTTP-500 for
http, some scary messages for ssh). Abort error have been properly reported for
"push" for a long time, there is not reason to be different for 'getbundle'. We
properly catch such error and report them back the best way available. For
bundle, we issue a valid bundle2 reply (as expected by the client) with an
'error:abort' part. With bundle1 we do as best as we can depending of http or
ssh.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:17:20 +0100] rev 30875
getbundle: cleanly handle remote abort during getbundle
bundle2 allow the server to report error explicitly. This was initially
implemented for push but there is not reason to not use it for pull too. This
changeset add logic similar to the one in 'unbundle' to the
client side of 'getbundle'. That logic make sure the error is properly reported
as "remote". This will allow the server side of getbundle to send clean "Abort"
message in the next changeset.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:06:08 +0100] rev 30874
bundle1: fix bundle1-denied reporting for pull over ssh
Changeset b288fb2724bf introduced a config option to have the server deny pull
using bundle1. The original protocol has not really been design to allow that
kind of error reporting so some hack was used. It turned the hack only works on
HTTP and that ssh server hangs forever when this is used. After further
digging, there is no way to report the error in a unified way. Using `ooberror`
freeze ssh and raising 'Abort' makes HTTP return a HTTP-500 without further
details. So with sadness we implement a version that dispatch according to the
protocol used.
Now the error is properly reported, but we still have ungraceful abort after
that. The protocol do not allow anything better to happen using bundle1.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 18:06:12 +0100] rev 30873
bundle-tests: operate from outside a repository
We are about to add a test for ssh pull/cloning being denied because of bundle1
usage. For this, it is cleaner to not operate from the clone using http. So we
update the test beforehand for clarity. This is more churns that what I'm happy
to see on stable, but the rests of the series is worth it in my opinion.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 17:56:52 +0100] rev 30872
bundle1: display server abort hint during unbundle
The code was printing the abort message but not the hint. This is now fixed.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 17:56:59 +0100] rev 30871
bundle1: fix bundle1-denied reporting for push over ssh
Changeset b288fb2724bf introduced a config option to have the server deny push
using bundle1. The original protocol has not really be design to allow such kind
of error reporting so some hack was used. It turned the hack only works on HTTP
and that ssh wire peer hangs forever when the same hack is used. After further
digging, there is no way to report the error in a unified way. Using 'ooberror'
freeze ssh and raising 'Abort' makes HTTP return a HTTP500 without further
details. So with sadness we implement a version that dispatch according to the
protocol used.
We also add a test for pushing over ssh to make sure we won't regress in the
future. That test show that the hint is missing, this is another bug fixed in
the next changeset.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 10 Feb 2017 17:56:47 +0100] rev 30870
bundle2: keep hint close to the primary message when remote abort
The remote hint message was ignored when reporting the remote error and
passed to the local generic abort error. I think I might initially have
tried to avoid reimplementing logic controlling the hint display depending of
the verbosity level. However, first, there does not seems to have such verbosity
related logic and second the resulting was wrong as the primary error and the
hint were split apart. We now properly print the hint as remote output.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 12 Feb 2017 02:23:33 +0900] rev 30869
misc: update year in copyright lines
This patch also makes some expected output lines in tests glob-ed for
persistence of them.
BTW, files below aren't yet changed in 2017, but this patch also
updates copyright of them, because:
- mercurial/help/hg.1.txt
almost all of "man hg" output comes from online help of hg
command, and is already changed in 2017
- mercurial/help/hgignore.5.txt
- mercurial/help/hgrc.5
"copyright 2005-201X Matt Mackall" in them mentions about
copyright of Mercurial itself
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 11 Feb 2017 00:23:55 +0900] rev 30868
misc: replace domain of mercurial-devel ML address by mercurial-scm.org
This patch also adds new check-code.py pattern to detect invalid usage
of "mercurial-devel@selenic.com".
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 11 Feb 2017 00:23:55 +0900] rev 30867
i18n: update Report-Msgid-Bugs-To property of *.po files
This patch replaces domain of mercurial-devel ML address by
mercurial-scm.org for "Report-Msgid-Bugs-To" property of each *.po
files.
This avoids releasing 4.1.1 with invalid "Report-Msgid-Bugs-To"
in *.mo file, if corresponded *.po file isn't msgmerge-ed with recent
hg.pot by translator.
These *.po files aren't covered by check-code.py pattern newly added
in subsequent patch, because it ignores them.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 11 Feb 2017 00:23:53 +0900] rev 30866
misc: replace domain of mercurial ML address by mercurial-scm.org
This patch also adds new check-code.py pattern to detect invalid usage
of "mercurial@selenic.com".
Change for test-convert-tla.t is tested, but similar change for almost
same test-convert-baz.t isn't yet tested actually, because I couldn't
find out the way to get "GNU Arch baz client".
AFAIK, buildbot skips test-convert-baz.t, too. Does anybody have
appropriate environment for testing?
Anton Shestakov <av6@dwimlabs.net> [Sat, 04 Feb 2017 20:29:34 +0800] rev 30865
debian: update copyright years
Anton Shestakov <av6@dwimlabs.net> [Sat, 04 Feb 2017 20:29:13 +0800] rev 30864
debian: update mailing list address
Kevin Bullock <kbullock@ringworld.org> [Wed, 01 Feb 2017 10:19:49 -0600] rev 30863
Added signature for changeset e1526da1e6d8
Kevin Bullock <kbullock@ringworld.org> [Wed, 01 Feb 2017 10:18:59 -0600] rev 30862
Added tag 4.1 for changeset e1526da1e6d8
Kevin Bullock <kbullock+mercurial@ringworld.org> [Wed, 01 Feb 2017 10:15:10 -0600] rev 30861
merge with i18n
Wagner Bruna <wbruna@softwareexpress.com.br> [Wed, 01 Feb 2017 08:47:11 -0200] rev 30860
i18n-pt_BR: synchronized with dfc6663f97ca
Mads Kiilerich <mads@kiilerich.com> [Wed, 01 Feb 2017 02:10:30 +0100] rev 30859
merge: more safe detection of criss cross merge conflict between dm and r
41f6af50c0d8 introduced handling of a crash in this case. A review comment
suggested that it was not entirely obvious that a 'dm' always would have a 'r'
for the source file.
To mitigate that risk, make the code more conservative and make less
assumptions.
Augie Fackler <augie@google.com> [Mon, 30 Jan 2017 18:03:17 -0500] rev 30858
tests: correct (I think) command in test-largefiles-update
When this test was introduced, it used the short-form of all the flags
on this update invocation. I suspect, based on the "start with clean
dirstates" comment and the fact that the no-exec branch of the #if
guard leaves dirstate clean, that this should have been 'update -qCr'
instead of 'update -qcr', but that a bug in largefiles --check
handling left this problem unnoticed.
I'll leave a breadcrumb further up about the current failure mode in
the hopes that we can fix this some day.
This was previously discussed in [0] but the trail in that thread goes
cold after a few replies. Given that this is still a flaky test, that
appears to only be passing by bad fortune, I think it's worth
correcting the code of the test to make a correct assertion, and to
keep track of the suspected bug with some other mechanism than an
invalid test (if we had support for "expected failure" blocks this
might be a worthwhile use of them?).
0: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089501.html
Augie Fackler <augie@google.com> [Mon, 30 Jan 2017 17:57:21 -0500] rev 30857
tests: expand flags to long form in test-largefiles-update.t
I spent some time confused by this test. I'm pretty sure that this
line intends to be cleaning the dirstate, not checking that it's clean
before updating: the preceding #if block leaves the dirstate clean in
the noexec case, and dirty in the exec case, so we can't expect
consistent behavior across that platform variation. A subsequent patch
will modify this command to use --clean instead of --check.
I'll elaborate in that patch about the hypothetical bug here.