Mon, 20 May 2019 14:33:46 -0400 contrib: add new examples area and start it out with a config for `hg fix`
Augie Fackler <augie@google.com> [Mon, 20 May 2019 14:33:46 -0400] rev 42965
contrib: add new examples area and start it out with a config for `hg fix` This is the configuration contributors should use for our C/C++ code. I expect to expand this file as we get more automated formatter oversight. Differential Revision: https://phab.mercurial-scm.org/D6872
Wed, 18 Sep 2019 06:04:59 +0200 tests: recognize DNS timeouts as well
Joerg Sonnenberger <joerg@bec.de> [Wed, 18 Sep 2019 06:04:59 +0200] rev 42964
tests: recognize DNS timeouts as well Differential Revision: https://phab.mercurial-scm.org/D6870
Tue, 17 Sep 2019 14:01:26 -0700 transaction: detect an attempt to truncate-to-extend on playback, raise error
Kyle Lippincott <spectral@google.com> [Tue, 17 Sep 2019 14:01:26 -0700] rev 42963
transaction: detect an attempt to truncate-to-extend on playback, raise error On some networked filesystems, writes can have delayed finalization/confirmation and write races can occur such that a remote modification will "win" and modifications will be lost. There is no functionality for providing this feedback to userspace programs (in fact, there's not even functionality for providing this information to the Linux kernel...), so these programs may see the files suddenly change. We've noticed that there have been cases where Mercurial has detected something has gone wrong and attempts to abort (rolling back the transaction), which is good. However, when rolling back the transaction, for the append-only files, we attempt to "truncate" the file back to the size it was in before the hg transaction started, but end up *extending* it. This may be harmless, but if this happens to the 00changelog.i file, we get a bunch of nulls on the end of the file and this causes hg to become *really* confused. :) If we detect that some modification of the file outside of this Mercurial process has caused the file to be smaller than the size we are attempting to truncate to, let's just exit and stop trying to clean up the repository - continuing will likely just cause more damage. Differential Revision: https://phab.mercurial-scm.org/D6867
Tue, 17 Sep 2019 15:09:25 -0700 osutil: tolerate Py_GetArgcArgv not being set up properly
Kyle Lippincott <spectral@google.com> [Tue, 17 Sep 2019 15:09:25 -0700] rev 42962
osutil: tolerate Py_GetArgcArgv not being set up properly Differential Revision: https://phab.mercurial-scm.org/D6866
Tue, 17 Sep 2019 14:57:42 -0700 osutil: allow disabling setprocname via a define passed to the compiler
Kyle Lippincott <spectral@google.com> [Tue, 17 Sep 2019 14:57:42 -0700] rev 42961
osutil: allow disabling setprocname via a define passed to the compiler In some situations, we run a custom python launcher that appears to not set up Py_GetArgcArgv correctly. We then proceed to promptly crash when we attempt to dereference NULL. Being able to completely disable setprocname is beneficial in these situations, since we won't even attempt to use it, even if the case that causes the crash is fixed. Right now, if I compile osutil.so with -DSETPROCNAME_USE_NONE, the compilation fails on python3 due to SETPROCNAME_USE_NONE redefinition. I could possibly work around that, but it's likely helpful to have a way of disabling this completely without it being brittle (i.e. if python3 ever gains the ability to perform this operation). Differential Revision: https://phab.mercurial-scm.org/D6865
Sun, 22 Sep 2019 14:33:56 +0700 stack: use repo.revs() instead of revsetlang.formatspec() + scmutil.revrange()
Anton Shestakov <av6@dwimlabs.net> [Sun, 22 Sep 2019 14:33:56 +0700] rev 42960
stack: use repo.revs() instead of revsetlang.formatspec() + scmutil.revrange() Using scmutil.revrange() it's possible to use multiple revsets at the same time, but we're not using that functionality in stack. I thought maybe that function could be used to make stack definition customizable (by combining various parts into one set), but scmutil.revrange() gives the union of all provided revsets, which is not very useful in stack's case (we want "and" between parts, not "or").
Mon, 23 Sep 2019 21:29:53 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Mon, 23 Sep 2019 21:29:53 +0900] rev 42959
merge with stable
Fri, 20 Sep 2019 23:31:03 +0700 merge: back out changeset a4ca0610c754 (parents order when grafting a merge) stable 5.1.2
Anton Shestakov <av6@dwimlabs.net> [Fri, 20 Sep 2019 23:31:03 +0700] rev 42958
merge: back out changeset a4ca0610c754 (parents order when grafting a merge) Turns out it's not enough to just swap parents, because when we do, there are unexpected bad side effects, such as a tracked file becoming untracked. These side effects need more code to be handled properly, but it's not written yet. Let's back this feature out from stable for now and some day implement it on default instead.
Sun, 01 Sep 2019 20:53:14 +0200 rust-hgpath: replace all paths and filenames with HgPath/HgPathBuf
Raphaël Gomès <rgomes@octobus.net> [Sun, 01 Sep 2019 20:53:14 +0200] rev 42957
rust-hgpath: replace all paths and filenames with HgPath/HgPathBuf Differential Revision: https://phab.mercurial-scm.org/D6774
Sun, 01 Sep 2019 20:53:14 +0200 rust-hgpath: add HgPath and HgPathBuf structs to encapsulate handling of paths
Raphaël Gomès <rgomes@octobus.net> [Sun, 01 Sep 2019 20:53:14 +0200] rev 42956
rust-hgpath: add HgPath and HgPathBuf structs to encapsulate handling of paths This change is a direct consequence of this discussion on the mailing list: https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-August/133574.html The implementations of `HgPath` and `HgPathBuf` are, for the most part, taken directly from `OsStr` and `OsString` respectively from the standard library. What this change does *not* yet do is implement the Windows MBCS to WTF8 conversion, but it lays the basis for a very flexible interface for paths. Differential Revision: https://phab.mercurial-scm.org/D6773
Wed, 18 Sep 2019 13:50:33 -0700 wireprototypes: clarify documentation of getbundle argument types
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Sep 2019 13:50:33 -0700] rev 42955
wireprototypes: clarify documentation of getbundle argument types It seems like it was a mix of what the Python code would see and what was sent over the wire. I've tried to clarify both the type seen in Python and how it's transmitted. Differential Revision: https://phab.mercurial-scm.org/D6871
Thu, 19 Sep 2019 07:50:24 +0900 merge with stable
Yuya Nishihara <yuya@tcha.org> [Thu, 19 Sep 2019 07:50:24 +0900] rev 42954
merge with stable
Wed, 18 Sep 2019 17:53:10 +0700 merge: respect parents order when using `graft` on a merge, this time for real stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 18 Sep 2019 17:53:10 +0700] rev 42953
merge: respect parents order when using `graft` on a merge, this time for real See a4ca0610c754. potherp1 is a boolean variable that means "pother is ctx.p1", and parents is naturally [ctx.p1, ctx.p2]. pctx is always removed from parents, so if pctx is parents[0], then we end up using parents[1] as pother. To be true to its name, potherp1 should then be True only when pctx is at parents[1].
Tue, 17 Sep 2019 15:35:16 -0700 py3: don't double-convert "opts" to bytes
Martin von Zweigbergk <martinvonz@google.com> [Tue, 17 Sep 2019 15:35:16 -0700] rev 42952
py3: don't double-convert "opts" to bytes The "opts" are already converted to bytes at the beginning of the function. Doing it twice results in a crash, which makes test-uncommit.t fail. The extra call was added recently, in ff1ff2aae132 (uncommit: add support to modify the commit message and date, 2019-09-07). test-uncommit.t passes again after this patch. Differential Revision: https://phab.mercurial-scm.org/D6864
Tue, 17 Sep 2019 21:06:07 +0100 py3: byte-prefix sanitisation regexes in phabricator.py
Ian Moody <moz-ian@perix.co.uk> [Tue, 17 Sep 2019 21:06:07 +0100] rev 42951
py3: byte-prefix sanitisation regexes in phabricator.py So it doesn't die with "TypeError: cannot use a string pattern on a bytes-like object". Differential Revision: https://phab.mercurial-scm.org/D6863
Wed, 18 Sep 2019 00:20:43 +0100 py3: pass a bytestring into querydrev instead of a string that'll TypeError
Ian Moody <moz-ian@perix.co.uk> [Wed, 18 Sep 2019 00:20:43 +0100] rev 42950
py3: pass a bytestring into querydrev instead of a string that'll TypeError This was a regression I introduced in c19d259fd6ad. When the string gets to the memoryview in _tokenize under py3 it'll die. Differential Revision: https://phab.mercurial-scm.org/D6869
Wed, 18 Sep 2019 00:05:52 +0100 py3: add test demonstrating TypeError when phabsending skips unchanged commits
Ian Moody <moz-ian@perix.co.uk> [Wed, 18 Sep 2019 00:05:52 +0100] rev 42949
py3: add test demonstrating TypeError when phabsending skips unchanged commits Skipping can currently only happen with `--no-amend`, so this isn't a usual configuration. Differential Revision: https://phab.mercurial-scm.org/D6868
Tue, 17 Sep 2019 15:07:08 -0400 tests: clean up built binaries after running test-fuzz-targets.t
Augie Fackler <augie@google.com> [Tue, 17 Sep 2019 15:07:08 -0400] rev 42948
tests: clean up built binaries after running test-fuzz-targets.t Most users won't notice a change here because they won't have the fuzzer infra, but by good fortune my workstation has the required bits and keeps leaving the fuzzer binaries around. Differential Revision: https://phab.mercurial-scm.org/D6862
Tue, 17 Sep 2019 14:22:22 -0400 fastannotate: remove support for flock() locking
Augie Fackler <augie@google.com> [Tue, 17 Sep 2019 14:22:22 -0400] rev 42947
fastannotate: remove support for flock() locking We've seen enough weirdness in CI with flock for remotefilelog that I'm now of the opinion we should just stop using flock() everywhere until someone has a concrete need for the extra performance *and* a way to only use it when safe (even if that's just default-to-off.) Differential Revision: https://phab.mercurial-scm.org/D6861
Tue, 17 Sep 2019 14:20:13 -0400 remotefilelog: remove dead code for using flock() for locking
Augie Fackler <augie@google.com> [Tue, 17 Sep 2019 14:20:13 -0400] rev 42946
remotefilelog: remove dead code for using flock() for locking Differential Revision: https://phab.mercurial-scm.org/D6860
Thu, 12 Sep 2019 21:55:45 -0700 narrow: add option for automatically removing unused includes
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Sep 2019 21:55:45 -0700] rev 42945
narrow: add option for automatically removing unused includes It's been a somewhat common request among our users to have Mercurial automatically pick includes to remove. This patch adds an option for that: `hg tracked --auto-remove-includes`. I'm not sure if this is the right name and semantics for it. Perhaps the feature should also add excludes of large subdirectories even if other files in the include are needed? Narrow clones are experimental, so we can change the name and/or semantics later if necessary. Differential Revision: https://phab.mercurial-scm.org/D6848
Thu, 12 Sep 2019 21:22:59 -0700 narrow: don't hexify paths and double-hexify known nodes on wire (BC)
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Sep 2019 21:22:59 -0700] rev 42944
narrow: don't hexify paths and double-hexify known nodes on wire (BC) It isn't obvious, but wireprototypes.encodelist() is meant only for binary nodeids. So when we used it for encoding hex nodeids and paths, the encoded result was surprising and hard to read. This patch changes the encoding to make the list of paths a comma-separated list and the list of common nodes to be a encodelist()-encoded list of binary nodeids (so the result is just singly-hexified nodeids). This is clearly a breaking change, but the feature is experimental and we're not aware of anyone running a server using this command yet. Differential Revision: https://phab.mercurial-scm.org/D6851
Wed, 11 Sep 2019 17:41:13 +0200 remotefilelog: replace repack lock to solve race condition
Boris Feld <boris.feld@octobus.net> [Wed, 11 Sep 2019 17:41:13 +0200] rev 42943
remotefilelog: replace repack lock to solve race condition 2c74337e6483 reduced the probability of race-conditions when starting background repack and prefetch and we saw the difference in our CI instance with all failures disappearing except one where one call to waitonrepack seems to returns too early. I'm not sure what exactly goes wrong but I realized that while the prefetch operation uses a standard Mercurial lock, the repack operation is using a custom lock based on `fcntl.flock` on available platforms. As `extutil.flock` fallback on traditional Mercurial locks on other platforms and the tests are stable on my laptop, our CI environment and GCC112, I'm sending this patch to standardize the behavior across environments. Differential Revision: https://phab.mercurial-scm.org/D6844
Tue, 17 Sep 2019 18:36:30 +0200 perf: add a --stats argument to perfhelper-pathcopies
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 17 Sep 2019 18:36:30 +0200] rev 42942
perf: add a --stats argument to perfhelper-pathcopies The arguments will display some statisting about the distribution of the value we measure.
Tue, 17 Sep 2019 09:49:30 +0200 perf: add a --stats argument to perfhelper-mergecopies
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 17 Sep 2019 09:49:30 +0200] rev 42941
perf: add a --stats argument to perfhelper-mergecopies The arguments will display some statistics about the distribution of the value we measure.
Tue, 17 Sep 2019 10:47:31 +0000 archive: add XZ support if built with Python 3
David Demelier <markand@malikania.fr> [Tue, 17 Sep 2019 10:47:31 +0000] rev 42940
archive: add XZ support if built with Python 3
Sun, 15 Sep 2019 22:43:32 +0900 rust-cpython: add sanity check to PySharedState::decrease_leak_count()
Yuya Nishihara <yuya@tcha.org> [Sun, 15 Sep 2019 22:43:32 +0900] rev 42939
rust-cpython: add sanity check to PySharedState::decrease_leak_count() If decrease_leak_count() were called unnecessarily, there must be a serious bug. It's better to not silently ignore such cases.
Sat, 14 Sep 2019 12:11:03 -0400 tests: stabilize test-fix.t on Windows
Matt Harbison <matt_harbison@yahoo.com> [Sat, 14 Sep 2019 12:11:03 -0400] rev 42938
tests: stabilize test-fix.t on Windows `pwd` prints /tmp/... style paths, not C:\... needed for $TESTTMP to be substituted. In the final test, for whatever reason, Windows was missing EOL in the files and printing: [wdir] changedlines: printf: warning: ignoring excess arguments, starting with 'printf' even though it was trying to run: printf "Line ranges:\n"; printf "2 through 2\n"; I tried wrapping both :command and :linerange in `sh -c "..."`, and while that fixed the missing EOL, it missed the "2 through 2" output. Differential Revision: https://phab.mercurial-scm.org/D6852
Sun, 15 Sep 2019 20:04:00 -0700 zstandard: vendor python-zstandard 0.12
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 15 Sep 2019 20:04:00 -0700] rev 42937
zstandard: vendor python-zstandard 0.12 The upstream source distribution from PyPI was extracted. Unwanted files were removed. The clang-format ignore list was updated to reflect the new source of files. test-repo-compengines.t was updated to reflect a change in behavior of the zstd library. The project contains a vendored copy of zstandard 1.4.3. The old version was 1.3.8. This should result in some minor performance wins. # no-check-commit because 3rd party code has different style guidelines Differential Revision: https://phab.mercurial-scm.org/D6858
Sun, 15 Sep 2019 00:07:30 -0400 uncommit: enable support for adding a note
Matt Harbison <matt_harbison@yahoo.com> [Sun, 15 Sep 2019 00:07:30 -0400] rev 42936
uncommit: enable support for adding a note This comes from the evolve extension's version of uncommit. The logic was already in place, and appears to be the last of the trivial things that can be enabled. Should these note options (including on amend) be marked advanced to keep the help text clutter level down? Differential Revision: https://phab.mercurial-scm.org/D6857
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip