Mon, 20 Oct 2014 22:08:08 +0900 tests: add "(glob)" to paths in test-hgrc.t for Windows stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 20 Oct 2014 22:08:08 +0900] rev 23056
tests: add "(glob)" to paths in test-hgrc.t for Windows
Mon, 20 Oct 2014 22:08:08 +0900 tests: add "(glob)" to paths in test-url-rev.t for Windows stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 20 Oct 2014 22:08:08 +0900] rev 23055
tests: add "(glob)" to paths in test-url-rev.t for Windows
Mon, 20 Oct 2014 22:08:08 +0900 tests: adjust expected prompt choice outputs in test-record.t for Windows stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 20 Oct 2014 22:08:08 +0900] rev 23054
tests: adjust expected prompt choice outputs in test-record.t for Windows Changeset 9ab18a912c44 introduced "showing prompt choice if input is not a tty but is forced to be interactive" and adjusted expected output in test-record.t. But some tests for no-execbit platform (= Windows) were not adjusted by 9ab18a912c44. This causes unexpected failure of test-record on Windows environment. This patch adds below to prompt lines for such tests: - prompt choice at the end of prompt line, and - empty line after prompt line
Tue, 21 Oct 2014 23:16:46 +0900 ui: separate option to show prompt echo, enabled only in tests (issue4417) stable
Yuya Nishihara <yuya@tcha.org> [Tue, 21 Oct 2014 23:16:46 +0900] rev 23053
ui: separate option to show prompt echo, enabled only in tests (issue4417) The problem in commandserver was addressed by 524b786bd54f, but it is tricky to reuse ui.nontty option to disable echo back. Instead, this patch introduces new option to enable echoing of prompt response. Prompt echoing is changed to be off by default, which should avoid possible breakage of output parsing in user scripts. For now, this option is undocumented because it exists for internal use.
Sat, 18 Oct 2014 18:14:48 -0500 Added signature for changeset 7f8d16af8cae stable
Matt Mackall <mpm@selenic.com> [Sat, 18 Oct 2014 18:14:48 -0500] rev 23052
Added signature for changeset 7f8d16af8cae
Sat, 18 Oct 2014 18:14:38 -0500 Added tag 3.2-rc for changeset 7f8d16af8cae stable
Matt Mackall <mpm@selenic.com> [Sat, 18 Oct 2014 18:14:38 -0500] rev 23051
Added tag 3.2-rc for changeset 7f8d16af8cae
Sat, 18 Oct 2014 18:05:10 -0500 merge with i18n stable 3.2-rc
Matt Mackall <mpm@selenic.com> [Sat, 18 Oct 2014 18:05:10 -0500] rev 23050
merge with i18n
Mon, 13 Oct 2014 14:46:50 +0100 i18n-ru: synchronized with 6b4dc7968bf0 stable
Alexander Sauta <demosito@gmail.com> [Mon, 13 Oct 2014 14:46:50 +0100] rev 23049
i18n-ru: synchronized with 6b4dc7968bf0
Sat, 18 Oct 2014 18:04:31 -0500 merge default into stable for 3.2 freeze stable
Matt Mackall <mpm@selenic.com> [Sat, 18 Oct 2014 18:04:31 -0500] rev 23048
merge default into stable for 3.2 freeze
Fri, 17 Oct 2014 02:17:36 -0700 hook: schedule run "b2x-transactionclose" for after lock release
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 02:17:36 -0700] rev 23047
hook: schedule run "b2x-transactionclose" for after lock release Hooks that run after the transaction need to be able to touch the repository. So we need to run them after the lock release. This is similar to what the "changegroup" hook is doing in the `addchangegroup` function.
Fri, 17 Oct 2014 15:25:32 -0700 repoview: issue a special message when filtering hidden changesets
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 15:25:32 -0700] rev 23046
repoview: issue a special message when filtering hidden changesets Hidden changesets are by far the most common error case and is the only one[1] that can reach the user. We move to a friendlier message with a hint about how to access the data anyway. We should probably point to a help topic instead but we do not have such a topic yet. Example of the new output abort: hidden revision '4'! (use --hidden to access hidden revisions) [1] Actually, filtering from "served" can also reach the user during certain exchange operations.
Fri, 17 Oct 2014 15:54:43 -0700 repoview: include the filter name in filtered revision error messages
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 15:54:43 -0700] rev 23045
repoview: include the filter name in filtered revision error messages This will help user to debug. A more precise message will be issued for the most common case ("visible" filter) in the next changesets. example output: - abort: filtered revision '4'! + abort: filtered revision '4' (not in 'visible' subset)!
Wed, 15 Oct 2014 05:08:56 +0200 largefiles: inline redundant toname function in status
Mads Kiilerich <madski@unity3d.com> [Wed, 15 Oct 2014 05:08:56 +0200] rev 23044
largefiles: inline redundant toname function in status Simpler and an optimization.
Wed, 15 Oct 2014 05:08:56 +0200 largefiles: inline redundant inctx function in status
Mads Kiilerich <madski@unity3d.com> [Wed, 15 Oct 2014 05:08:56 +0200] rev 23043
largefiles: inline redundant inctx function in status
Fri, 17 Oct 2014 18:56:12 +0200 ssl: only use the dummy cert hack if using an Apple Python (issue4410)
Mads Kiilerich <madski@unity3d.com> [Fri, 17 Oct 2014 18:56:12 +0200] rev 23042
ssl: only use the dummy cert hack if using an Apple Python (issue4410) The hack for using certificate store in addition to the provided CAs resides in Apple's OpenSSL. Apple's own Pythons will use it, but other custom built Pythons might use a custom built OpenSSL without that hack and will fail when exposed to the dummy cacert introduced in d7f7f1860f00. There do not seem to be a simple way to check from Python if we are using a patched OpenSSL or if it is an Apple OpenSSL. Instead, check if the Python executable resides in /usr/bin/python* or in /System/Library/Frameworks/Python.framework/ and assume that all Pythons found there will be native Pythons using the patched OpenSSL. Custom built Pythons will not get the benefit of using the CAs from the certificate store.
Wed, 15 Oct 2014 05:08:56 +0200 largefiles: move initialization of standins variable to clarify its "scope"
Mads Kiilerich <madski@unity3d.com> [Wed, 15 Oct 2014 05:08:56 +0200] rev 23041
largefiles: move initialization of standins variable to clarify its "scope"
Wed, 15 Oct 2014 05:08:56 +0200 largefiles: the update override only needs lfdirstate and status for --check
Mads Kiilerich <madski@unity3d.com> [Wed, 15 Oct 2014 05:08:56 +0200] rev 23040
largefiles: the update override only needs lfdirstate and status for --check
Fri, 03 Oct 2014 00:42:40 +0200 largefiles: remove confusing rev parameter for lfdirstatestatus
Mads Kiilerich <madski@unity3d.com> [Fri, 03 Oct 2014 00:42:40 +0200] rev 23039
largefiles: remove confusing rev parameter for lfdirstatestatus Dirstate only works on the repo wctx.
Fri, 03 Oct 2014 00:42:40 +0200 largefiles: replace repo._isaddremove hack with a simple function parameter
Mads Kiilerich <madski@unity3d.com> [Fri, 03 Oct 2014 00:42:40 +0200] rev 23038
largefiles: replace repo._isaddremove hack with a simple function parameter
Sun, 12 Oct 2014 22:23:43 -0700 status: add more complete tests for --rev
Martin von Zweigbergk <martinvonz@gmail.com> [Sun, 12 Oct 2014 22:23:43 -0700] rev 23037
status: add more complete tests for --rev The 'status --rev' code is not very well tested, which has bitten us as recently as in issue4321. Let's add some more tests, some of which uncover bugs. Remove the few existing tests that are now covered in a more thorough and consistent way.
Sat, 18 Oct 2014 12:24:50 +0900 cmdserver: include pid of server handling requests in hello message
Yuya Nishihara <yuya@tcha.org> [Sat, 18 Oct 2014 12:24:50 +0900] rev 23036
cmdserver: include pid of server handling requests in hello message Because unix-mode server forks child process per connection, client does not know the pid of the server that will handle requests. The pid is necessary to interrupt hung process: 1. client connects to socket server 2. server accepts the connection, forks, and tells pid 3. client requests "runcommand pull" .. hung .. 4. client sends SIGINT to the (forked) server 5. server returns from I/O wait Note that getsockopt(SO_PEERCRED) of Linux cannot be used because the server fork()s after accept().
Sat, 18 Oct 2014 21:52:11 +0900 run-tests: clean up unused globals that were removed by tests-refactor series
Yuya Nishihara <yuya@tcha.org> [Sat, 18 Oct 2014 21:52:11 +0900] rev 23035
run-tests: clean up unused globals that were removed by tests-refactor series They were demoted to instance variables by cb88d4a04f58, 1ad7aabba14e, 93511a595766, 2e1aa8c1ee37, 8e7b0f4d6ac7 and 02087bc4f143.
Thu, 16 Oct 2014 17:44:37 +0200 docker: use official centos5 image
Mads Kiilerich <madski@unity3d.com> [Thu, 16 Oct 2014 17:44:37 +0200] rev 23034
docker: use official centos5 image I guess it didn't exist when centos5 support was introduced.
Thu, 16 Oct 2014 17:44:14 +0200 docker: add centos7 target for CentOS / Red Hat 7 support
Mads Kiilerich <madski@unity3d.com> [Thu, 16 Oct 2014 17:44:14 +0200] rev 23033
docker: add centos7 target for CentOS / Red Hat 7 support
Thu, 16 Oct 2014 19:15:51 -0700 lock: while releasing, unlink lockfile even if the release function throws
Siddharth Agarwal <sid0@fb.com> [Thu, 16 Oct 2014 19:15:51 -0700] rev 23032
lock: while releasing, unlink lockfile even if the release function throws Consider a hypothetical bug in the release function that causes it to raise an exception. Also consider the bisect command, which saves its state in a finally clause. Saving the state requires acquiring the wlock. If we don't unlink the lockfile when the exception is thrown, we'll try to acquire the wlock again. We're going to try and acquire a lock again while our old lockfile is on disk. The PID on disk is our own, and of course we're still running, so we won't take over the lock. Hence we'll be stuck waiting for a lock that we left behind ourselves. To avoid this, always unlink the lockfile. This preserves the invariant that self.held > 0 is equivalent to the lockfile existing on disk.
Fri, 17 Oct 2014 13:52:10 -0400 i18n: cache the result of every gettext call
Augie Fackler <raf@durin42.com> [Fri, 17 Oct 2014 13:52:10 -0400] rev 23031
i18n: cache the result of every gettext call In looking at profiler output for 'hg log' on mozilla-central, I noticed we spent a _huge_ amount of time in gettext relative to what it's doing. Caching provides a roughly 15% performance improvement even on repositories as small as hg. == hg repo on linux == Before: % cumulative self time seconds seconds name 5.05 0.19 0.19 i18n.py:62:gettext 4.84 0.18 0.18 revlog.py:88:decompress 2.95 0.17 0.11 changelog.py:201:node 2.32 0.09 0.09 ui.py:577:write 2.11 0.08 0.08 i18n.py:72:gettext 2.11 0.08 0.08 obsolete.py:196:_fm0readmarkers 1.89 0.07 0.07 obsolete.py:569:_load 1.68 0.63 0.06 localrepo.py:29:__get__ real 0m4.026s user 0m3.993s sys 0m0.034s After: % cumulative self time seconds seconds name 8.05 0.26 0.26 revlog.py:88:decompress 2.68 0.22 0.09 color.py:395:write 2.20 0.07 0.07 obsolete.py:196:_fm0readmarkers 1.95 0.06 0.06 obsolete.py:174:_fm0readmarkers 1.95 0.06 0.06 ui.py:577:write 1.95 0.06 0.06 util.py:1228:datestr 1.71 0.06 0.06 utf_8.py:16:decode 1.71 0.06 0.06 revlog.py:273:__len__ real 0m3.519s user 0m3.447s sys 0m0.073s == mozilla-central repo on linux == Before: % cumulative self time seconds seconds name 7.72 2.35 2.35 revlog.py:88:decompress 4.46 1.36 1.36 i18n.py:62:gettext 2.22 0.67 0.67 i18n.py:72:gettext 2.19 1.14 0.67 changelog.py:201:node 2.16 0.66 0.66 ui.py:577:write 1.96 0.60 0.60 utf_8.py:16:decode 1.93 1.97 0.59 color.py:395:write 1.85 0.81 0.56 changelog.py:136:tip real 0m30.822s user 0m30.660s sys 0m0.149s After: % cumulative self time seconds seconds name 9.82 2.49 2.49 revlog.py:88:decompress 2.67 1.31 0.68 localrepo.py:29:__get__ 2.57 0.65 0.65 utf_8.py:16:decode 2.48 1.01 0.63 changelog.py:201:node 2.10 0.82 0.53 changelog.py:136:tip 2.01 0.51 0.51 ui.py:577:write 1.91 0.49 0.49 util.py:1232:datestr 1.85 1.65 0.47 color.py:395:write real 0m25.619s user 0m25.446s sys 0m0.166s == cpython repo on os x = Before: % cumulative self time seconds seconds name 5.05 1.35 1.35 cmdutil.py:982:_show 4.59 1.22 1.22 revlog.py:274:__len__ 3.98 1.06 1.06 i18n.py:62:gettext 3.91 1.04 1.04 revlog.py:1016:revision 3.68 0.98 0.98 revlog.py:337:parents 3.45 0.92 0.92 revlog.py:88:decompress 2.91 0.78 0.78 revlog.py:309:rev 2.62 0.70 0.70 revlog.py:1033:revision real 0m30.414s user 0m28.145s sys 0m0.541s After: % cumulative self time seconds seconds name 7.98 1.66 1.66 cmdutil.py:982:_show 6.83 1.42 1.42 changelog.py:46:decodeextra 5.18 1.08 1.08 revlog.py:274:__len__ 3.94 0.82 0.82 revlog.py:1016:revision 3.41 0.71 0.71 revlog.py:309:rev 3.32 0.69 0.69 revlog.py:88:decompress 2.99 0.63 0.62 revlog.py:1033:revision 2.69 0.56 0.56 revlog.py:341:start real 0m22.811s user 0m21.883s sys 0m0.397s
Sat, 30 Aug 2014 17:38:14 +0200 util.system: avoid buffering of subprocess output when it is piped
Yuya Nishihara <yuya@tcha.org> [Sat, 30 Aug 2014 17:38:14 +0200] rev 23030
util.system: avoid buffering of subprocess output when it is piped util.system() copies subprocess' output through pipe if output file is not stdout. Because a file iterator has internal buffering, output won't be flushed until enough data is available. Therefore, it could easily miss important messages such as "waiting for lock".
Fri, 17 Oct 2014 09:57:05 +0900 bundle2: client side support for a part to import external bundles
Mike Hommey <mh@glandium.org> [Fri, 17 Oct 2014 09:57:05 +0900] rev 23029
bundle2: client side support for a part to import external bundles Bundle2 opens doors to advanced features allowing to reduce load on mercurial servers, and improve clone experience for users on unstable or slow networks. For instance, it could be possible to pre-generate a bundle of a repository, and give a pointer to it to clients cloning the repository, followed by another changegroup with the remainder. For significantly big repositories, this could come as several base bundles with e.g. 10k changesets, which, combined with checkpoints (not part of this change), would prevent users with flaky networks from starting over any time their connection fails. While the server-side support for those features doesn't exist yet, it is preferable to have client-side support for this early-on, allowing experiments on servers only requiring a vanilla client with bundle2 enabled.
Thu, 25 Sep 2014 11:53:28 +0900 bundle2: remove _getbundleextrapart
Mike Hommey <mh@glandium.org> [Thu, 25 Sep 2014 11:53:28 +0900] rev 23028
bundle2: remove _getbundleextrapart Extensions can now add new part generators with the getbundle2partsgenerator decorator instead.
Fri, 17 Oct 2014 12:34:27 -0500 glossary: add deprecated and experimental
Matt Mackall <mpm@selenic.com> [Fri, 17 Oct 2014 12:34:27 -0500] rev 23027
glossary: add deprecated and experimental
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip