Sat, 25 Feb 2017 16:57:21 +0530 ui: replace obsolete default-push with default:pushurl (issue5485) stable
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.
Sat, 25 Feb 2017 01:07:52 +0900 worker: ignore meaningless exit status indication returned by os.waitpid() stable
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
Mon, 13 Feb 2017 11:43:12 -0800 bundle2: fix assertion that 'compression' hasn't been set stable
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`.
Fri, 10 Feb 2017 18:20:58 +0100 wireproto: properly report server Abort during 'getbundle' stable
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.
Fri, 10 Feb 2017 18:17:20 +0100 getbundle: cleanly handle remote abort during getbundle stable
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.
Fri, 10 Feb 2017 18:06:08 +0100 bundle1: fix bundle1-denied reporting for pull over ssh stable
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.
Fri, 10 Feb 2017 18:06:12 +0100 bundle-tests: operate from outside a repository stable
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.
Fri, 10 Feb 2017 17:56:52 +0100 bundle1: display server abort hint during unbundle stable
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.
Fri, 10 Feb 2017 17:56:59 +0100 bundle1: fix bundle1-denied reporting for push over ssh stable
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.
Fri, 10 Feb 2017 17:56:47 +0100 bundle2: keep hint close to the primary message when remote abort stable
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.
Sun, 12 Feb 2017 02:23:33 +0900 misc: update year in copyright lines stable
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
Sat, 11 Feb 2017 00:23:55 +0900 misc: replace domain of mercurial-devel ML address by mercurial-scm.org stable
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".
Sat, 11 Feb 2017 00:23:55 +0900 i18n: update Report-Msgid-Bugs-To property of *.po files stable
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.
Sat, 11 Feb 2017 00:23:53 +0900 misc: replace domain of mercurial ML address by mercurial-scm.org stable
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?
(0) -30000 -10000 -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 +3000 +10000 tip