Sat, 07 Sep 2019 00:34:20 +0200 flagprocessors: remove flagprocessorsmixin
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 00:34:20 +0200] rev 42997
flagprocessors: remove flagprocessorsmixin It became an empty shell. Differential Revision: https://phab.mercurial-scm.org/D6823
Sat, 07 Sep 2019 00:26:15 +0200 flagprocessors: move _flagserrorclass attribute on revlog & co
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 00:26:15 +0200] rev 42996
flagprocessors: move _flagserrorclass attribute on revlog & co This is a small duplication, and the last bit we need to get rid of the mixin. Honestly, I am not fan of that class attribute and it mostly exist to accomodate The simple-storage whose usage of flag processors is dumbious and that is currently dead code anyway. However I don't want to be pulled into futher unrelated cleaning so it is a small price to pay. Differential Revision: https://phab.mercurial-scm.org/D6822
Sat, 07 Sep 2019 00:22:38 +0200 flagprocessors: directly duplicate the deprecated layer back into revlog
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 00:22:38 +0200] rev 42995
flagprocessors: directly duplicate the deprecated layer back into revlog The code duplication benign and will get removed in a couple of month anyway. Differential Revision: https://phab.mercurial-scm.org/D6821
Sat, 07 Sep 2019 00:16:32 +0200 flagprocessors: make `processflagsraw` a module level function
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 00:16:32 +0200] rev 42994
flagprocessors: make `processflagsraw` a module level function One more steps toward removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6820
Sat, 07 Sep 2019 00:11:58 +0200 flagprocessors: make `processflagsread` a module level function
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 00:11:58 +0200] rev 42993
flagprocessors: make `processflagsread` a module level function One more steps toward removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6819
Fri, 06 Sep 2019 23:50:32 +0200 flagprocessors: make `processflagswrite` a module level function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Sep 2019 23:50:32 +0200] rev 42992
flagprocessors: make `processflagswrite` a module level function One more step towards removing the mixin. Differential Revision: https://phab.mercurial-scm.org/D6818
Fri, 06 Sep 2019 23:43:06 +0200 flagprocessors: make `_processflagsfunc` a module level function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Sep 2019 23:43:06 +0200] rev 42991
flagprocessors: make `_processflagsfunc` a module level function This is the first step toward removing the flag processing mixin. Differential Revision: https://phab.mercurial-scm.org/D6817
Wed, 04 Sep 2019 00:53:27 +0200 flagprocessors: writetransform function take side data as parameter (API)
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 04 Sep 2019 00:53:27 +0200] rev 42990
flagprocessors: writetransform function take side data as parameter (API) If we want some flag processors to be able to store sidedata it needs to be actually fed that data. Differential Revision: https://phab.mercurial-scm.org/D6816
Tue, 03 Sep 2019 23:51:17 +0200 flagprocessors: add a `sidedata` parameters to _processflagswrite
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Sep 2019 23:51:17 +0200] rev 42989
flagprocessors: add a `sidedata` parameters to _processflagswrite To read sidedata using flagprocessors, we need flag processors to store them. So we pass this information to the flag processing layer. Differential Revision: https://phab.mercurial-scm.org/D6815
Tue, 03 Sep 2019 23:51:34 +0200 revlog: add a `sidedata` parameters to addrevision
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Sep 2019 23:51:34 +0200] rev 42988
revlog: add a `sidedata` parameters to addrevision If we want to eventually store sidedata we need to be able to pass them along. Differential Revision: https://phab.mercurial-scm.org/D6814
Wed, 04 Sep 2019 00:34:03 +0200 flagprocessors: have the read transform function return side data (API)
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 04 Sep 2019 00:34:03 +0200] rev 42987
flagprocessors: have the read transform function return side data (API) This makes it possible for flag processors to -read- flag data. Differential Revision: https://phab.mercurial-scm.org/D6813
Wed, 04 Sep 2019 00:13:45 +0200 flagprocessors: return flagdata in the main processing function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 04 Sep 2019 00:13:45 +0200] rev 42986
flagprocessors: return flagdata in the main processing function This function input and return are becoming stranger and stranger bnut I don't have a good plan to make is saner without problematic code duplication, so it will be this way to now. Differential Revision: https://phab.mercurial-scm.org/D6812
Tue, 03 Sep 2019 22:55:04 +0200 flagprocessors: return sidedata map in `_processflagsread`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Sep 2019 22:55:04 +0200] rev 42985
flagprocessors: return sidedata map in `_processflagsread` Right now, flag processors does not return sidedata, by they will. So, we prepare the caller to receive it. Differential Revision: https://phab.mercurial-scm.org/D6811
Tue, 03 Sep 2019 22:36:41 +0200 revlog: use the new sidedata map return in the sidedata method
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Sep 2019 22:36:41 +0200] rev 42984
revlog: use the new sidedata map return in the sidedata method So far things, seems logical. Differential Revision: https://phab.mercurial-scm.org/D6810
Tue, 03 Sep 2019 22:54:04 +0200 revlog: return sidedata map from `_revisiondata`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Sep 2019 22:54:04 +0200] rev 42983
revlog: return sidedata map from `_revisiondata` Nothing extra any side data yet. However, it will happens in the future. So we better prepare the callers of the `_revisiondata` to deal with it. Differential Revision: https://phab.mercurial-scm.org/D6809
Tue, 03 Sep 2019 22:36:27 +0200 revlog: introduce a `sidedata` method
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 03 Sep 2019 22:36:27 +0200] rev 42982
revlog: introduce a `sidedata` method The method give access to extra information related to the revision. Such data will not be part of the hash be strongly related to the revision. Having them stored at the revlog level helps the storage consistency story and simplify various things. Example of data we could store there: - copy tracing related informations - graph structure related information (useful for discovery) - unresolved conflict data The full implementation will be introduced gradually in the coming changesets. Differential Revision: https://phab.mercurial-scm.org/D6808
Wed, 25 Sep 2019 14:35:08 -0700 update: clarify calculateupdate() call sites by specifying argument names
Martin von Zweigbergk <martinvonz@google.com> [Wed, 25 Sep 2019 14:35:08 -0700] rev 42981
update: clarify calculateupdate() call sites by specifying argument names merge.calculateupdate() takes a lot of parameters and I get confused all the time which is which. See also b14fdf1fb615 (update: clarify update() call sites by specifying argument names, 2017-02-09). Differential Revision: https://phab.mercurial-scm.org/D6883
Wed, 25 Sep 2019 17:57:16 -0400 bookmarks: remove changectx() method from bmstore (API)
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 17:57:16 -0400] rev 42980
bookmarks: remove changectx() method from bmstore (API) All the callsites of this method have access to the repo, and I'd rather not have to duplicate this across alternative bmstore implementations. Besides, it feels like a bit of a layering violation. .. api:: `mercurial.bookmarks.bmstore` no longer has a convenience method for looking up changectx instances from a bookmark name. Use `repo[repo.bookmarks[name]]` intead of `repo.bookmarks.changectx(name)`. Differential Revision: https://phab.mercurial-scm.org/D6884
Wed, 25 Sep 2019 13:50:48 -0400 histedit: sniff-test for untracked file conflicts before prompting for rules
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 13:50:48 -0400] rev 42979
histedit: sniff-test for untracked file conflicts before prompting for rules This bug is as old as histedit, which is more than 10 years! I'm a little sad about the extra calculations here that we're just going to throw out, but I don't see any better way to look for untracked file conflicts and I want the bug fixed. Differential Revision: https://phab.mercurial-scm.org/D6882
Mon, 23 Sep 2019 16:29:16 -0400 histedit: demonstrate breakage when `update` to a revision breaks
Augie Fackler <augie@google.com> [Mon, 23 Sep 2019 16:29:16 -0400] rev 42978
histedit: demonstrate breakage when `update` to a revision breaks I'm honestly impressed that nobody has hit this in the over a decade that histedit has existed, but here we are. Differential Revision: https://phab.mercurial-scm.org/D6881
Wed, 25 Sep 2019 10:59:29 -0400 rebase: track new nodes when --keep is set
Paul Gossman <pgossman@janestreet.com> [Wed, 25 Sep 2019 10:59:29 -0400] rev 42977
rebase: track new nodes when --keep is set When --keep is passed with rebase, the new nodes created are not accessible from templates. This change enables accessing the newly-created nodes from nodechanges, just as if --keep was not set. Differential Revision: https://phab.mercurial-scm.org/D6880
Sat, 21 Sep 2019 13:42:23 -0400 uncommit: fix typo in help text
Matt Harbison <matt_harbison@yahoo.com> [Sat, 21 Sep 2019 13:42:23 -0400] rev 42976
uncommit: fix typo in help text Differential Revision: https://phab.mercurial-scm.org/D6874
Tue, 24 Sep 2019 22:41:07 -0400 phabricator: use exthelper to register commands, config, and templates
Matt Harbison <matt_harbison@yahoo.com> [Tue, 24 Sep 2019 22:41:07 -0400] rev 42975
phabricator: use exthelper to register commands, config, and templates Differential Revision: https://phab.mercurial-scm.org/D6875
Wed, 25 Sep 2019 11:04:08 -0400 merge: check argument value with if/raise instead of an assert
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 11:04:08 -0400] rev 42974
merge: check argument value with if/raise instead of an assert This shouldn't make any difference for legal code, but it'll prevent the assertion from being optimized out if someone decides to do -O on our code. Differential Revision: https://phab.mercurial-scm.org/D6879
Wed, 25 Sep 2019 11:02:32 -0400 hg: have `updatetotally` more thoroughly check updatecheck argument (API)
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 11:02:32 -0400] rev 42973
hg: have `updatetotally` more thoroughly check updatecheck argument (API) .. api:: `mercurial.hg.updatetotally` is now more thorough about checking its `updatecheck` keyword argument. Previously invalid values would have used the configured default updatecheck method, but now will raise ValueError. Differential Revision: https://phab.mercurial-scm.org/D6878
Wed, 25 Sep 2019 10:53:10 -0400 merge: replace magic strings with NAMED_CONSTANTS (API)
Augie Fackler <augie@google.com> [Wed, 25 Sep 2019 10:53:10 -0400] rev 42972
merge: replace magic strings with NAMED_CONSTANTS (API) .. api:: `mercurial.hg.update*` and `mercurial.merge.update` now expect a value from a set of NAMED_CONSTANTS (`merge.UPDATECHECK_*` constants) rather than a collection of magic strings. As of now, the values are the same, but code should be prepared for these values to change in the future. Differential Revision: https://phab.mercurial-scm.org/D6877
Wed, 25 Sep 2019 12:59:26 +0200 singlehead: introduce special handling of closed heads
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Sep 2019 12:59:26 +0200] rev 42971
singlehead: introduce special handling of closed heads Until now, the experimental option `single-head-per-branch` was also refusing closed heads. The logic is now ignoring them by default and a suboption have been added to refuse them too `single-head-per-branch:account-closed-heads`.
Wed, 25 Sep 2019 12:57:11 +0200 testlib: allow more argument to mkcommit
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Sep 2019 12:57:11 +0200] rev 42970
testlib: allow more argument to mkcommit This is simple and handy. See next changesets for usage.
Wed, 25 Sep 2019 12:35:34 +0200 singlehead: fix a small typo in a test comment
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Sep 2019 12:35:34 +0200] rev 42969
singlehead: fix a small typo in a test comment The sentence is now correct.
Mon, 20 May 2019 14:37:38 -0400 examples: add sample fix integration for `rustfmt`
Augie Fackler <augie@google.com> [Mon, 20 May 2019 14:37:38 -0400] rev 42968
examples: add sample fix integration for `rustfmt` Differential Revision: https://phab.mercurial-scm.org/D6873
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 42967
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 42966
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 42965
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 42964
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 42963
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 42962
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 42961
merge with stable
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 42960
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 42959
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 42958
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 42957
merge with stable
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 42956
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 42955
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 42954
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 42953
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 42952
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 42951
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 42950
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 42949
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 42948
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 42947
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 42946
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 42945
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 42944
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 42943
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 42942
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 42941
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 42940
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
Sat, 14 Sep 2019 23:41:31 -0400 amend: enable support for using the secret phase
Matt Harbison <matt_harbison@yahoo.com> [Sat, 14 Sep 2019 23:41:31 -0400] rev 42939
amend: enable support for using the secret phase This comes from the evolve extension's version of amend. The logic was already in place, and appears to be the last of the trivial things that can be enabled. Differential Revision: https://phab.mercurial-scm.org/D6856
Sat, 14 Sep 2019 23:40:12 -0400 amend: enable support for closing the branch
Matt Harbison <matt_harbison@yahoo.com> [Sat, 14 Sep 2019 23:40:12 -0400] rev 42938
amend: enable support for closing the branch This comes from the evolve extension's version of amend. The logic was already in place. Differential Revision: https://phab.mercurial-scm.org/D6855
Sat, 14 Sep 2019 18:44:18 -0400 amend: prevent '\n' in the note string
Matt Harbison <matt_harbison@yahoo.com> [Sat, 14 Sep 2019 18:44:18 -0400] rev 42937
amend: prevent '\n' in the note string This comes from the evolve function. I'm not sure why this check was missing in core, since it was present when the length check was added to evolve. I didn't flag this as BC because 530b7361e3a9 mentioned this argument wasn't added to the release notes due to no display capability, and that hasn't changed AFAIK. Differential Revision: https://phab.mercurial-scm.org/D6854
Sat, 14 Sep 2019 15:13:16 -0400 amend: add option to update to the current user
Matt Harbison <matt_harbison@yahoo.com> [Sat, 14 Sep 2019 15:13:16 -0400] rev 42936
amend: add option to update to the current user This is also from the evolve extension's version of amend. A side effect of this refactoring is for uncommit to support `rewrite.update-timestamp`. Differential Revision: https://phab.mercurial-scm.org/D6853
Wed, 11 Sep 2019 15:03:08 -0700 bundle2: fix an off-by-one in debug message of number of parts
Martin von Zweigbergk <martinvonz@google.com> [Wed, 11 Sep 2019 15:03:08 -0700] rev 42935
bundle2: fix an off-by-one in debug message of number of parts Differential Revision: https://phab.mercurial-scm.org/D6850
Thu, 12 Sep 2019 22:31:45 -0700 tests: move a config write to top of file since it applies to all tests
Martin von Zweigbergk <martinvonz@google.com> [Thu, 12 Sep 2019 22:31:45 -0700] rev 42934
tests: move a config write to top of file since it applies to all tests I'm about to add another test that depends on this config. Differential Revision: https://phab.mercurial-scm.org/D6849
Tue, 10 Sep 2019 09:57:33 -0400 idirstate: group private methods and attrs that are in the interface
Augie Fackler <augie@google.com> [Tue, 10 Sep 2019 09:57:33 -0400] rev 42933
idirstate: group private methods and attrs that are in the interface This makes it a little more obvious at a glance what work is left. Fortunately there's not a whole lot left. I suspect the ignore logic is going to be the tricky bit. Differential Revision: https://phab.mercurial-scm.org/D6839
Tue, 10 Sep 2019 09:42:56 -0400 idirstate: remove now non-public _map attribute
Augie Fackler <augie@google.com> [Tue, 10 Sep 2019 09:42:56 -0400] rev 42932
idirstate: remove now non-public _map attribute Differential Revision: https://phab.mercurial-scm.org/D6838
Tue, 10 Sep 2019 09:21:38 -0400 interfaces: introduce an interface for dirstate implementations
Augie Fackler <augie@google.com> [Tue, 10 Sep 2019 09:21:38 -0400] rev 42931
interfaces: introduce an interface for dirstate implementations As usual with adding interface definitions, this describes the way things are, not the way we'd like things to be. There are some clear problems in the interface right now (eg ._map leaks in a few places), but I have plans to clean those up. There are also many missing docstrings, but again, we'll make a second pass to clean that up. Differential Revision: https://phab.mercurial-scm.org/D6836
Tue, 10 Sep 2019 09:41:58 -0400 cleanup: fix leakage of dirstate._map to client code
Augie Fackler <augie@google.com> [Tue, 10 Sep 2019 09:41:58 -0400] rev 42930
cleanup: fix leakage of dirstate._map to client code We already had proper accessors for most of the behavior of dirstate._map that callers cared about exposed in the actual dirstate class as public methods. Sigh. There are two remaining privacy violations in the codebase after this change: 1) In the perf extension, which I suspect has to stick around because it's really testing the dirstate implementation directly 2) In largefiles, where we deal with standins and mutating status. Looking at this, I _strongly_ suspect a formal dirstate interface would allow this to work via composition instead of inheritance and monkeypatching. Fortunately, such wins are a part of my motivation for this work. I anticipate we'll come back to this in due time. Differential Revision: https://phab.mercurial-scm.org/D6837
Sun, 08 Sep 2019 20:26:36 -0400 exchange: convert bookmark nodes from hex to bin ASAP
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 08 Sep 2019 20:26:36 -0400] rev 42929
exchange: convert bookmark nodes from hex to bin ASAP Differential Revision: https://phab.mercurial-scm.org/D6831
Sun, 08 Sep 2019 20:10:32 -0400 exchange: avoid unnecessary conversion of bookmark nodes to hex (API)
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 08 Sep 2019 20:10:32 -0400] rev 42928
exchange: avoid unnecessary conversion of bookmark nodes to hex (API) Differential Revision: https://phab.mercurial-scm.org/D6830
Mon, 09 Sep 2019 14:26:43 -0400 highlight: fix encoding issues to enable Py3 compatibility
Connor Sheehan <sheehan@mozilla.com> [Mon, 09 Sep 2019 14:26:43 -0400] rev 42927
highlight: fix encoding issues to enable Py3 compatibility This commit fixes various encoding issues with the `highlight` extension to enable compatibility with Python 3. Python `.encode()` and `.decode()` requires the target encoding to be passed as a `str`, so the value of `mercurial.encoding.encoding` must be converted before passing to the function. Pygments also assumes the `str` type for values it works with, so we must perform conversions before and after receiving values from its APIs. After applying this patch, `test-highlight.t` passes under Python 3. We add it to `python3-whitelist` as well. Tested with Pygments 2.4.2. Differential Revision: https://phab.mercurial-scm.org/D6832
Tue, 10 Sep 2019 12:32:07 -0400 hgweb: add a `message` attribute to `hgweb.common.ErrorResponse`
Connor Sheehan <sheehan@mozilla.com> [Tue, 10 Sep 2019 12:32:07 -0400] rev 42926
hgweb: add a `message` attribute to `hgweb.common.ErrorResponse` This fixes a Python 3 bug where hgweb assumes an Exception subclass will have a `.message` attribute after running `Exception.__init__`.[1] The Python 3 way to get this info would be `e.args[0]`, but adding a new named attribute is more ergonomic in my view. [1] https://www.mercurial-scm.org/repo/hg-committed/file/6ccf539aec71/mercurial/hgweb/hgwebdir_mod.py#l459 Differential Revision: https://phab.mercurial-scm.org/D6840
Tue, 10 Sep 2019 22:52:04 -0400 uncommit: make -D/--date and -U/--user mutually exclusive
Matt Harbison <matt_harbison@yahoo.com> [Tue, 10 Sep 2019 22:52:04 -0400] rev 42925
uncommit: make -D/--date and -U/--user mutually exclusive This is how amend and graft work (but not MQ). I'm not sure why this didn't work for me when I first tried it. Differential Revision: https://phab.mercurial-scm.org/D6842
Tue, 10 Sep 2019 22:04:22 -0400 uncommit: drop the hyphen from --current-user and --current-date
Matt Harbison <matt_harbison@yahoo.com> [Tue, 10 Sep 2019 22:04:22 -0400] rev 42924
uncommit: drop the hyphen from --current-user and --current-date I didn't pay enough attention to these long forms- graft, amend and MQ already use the old style naming. It's probably more important to be consistent than modern. The hypenated style came from evolve. Yuya mentioned this naming discrepancy in 4145fd3569c3, but it didn't attract any discussion[1]. There's also a bit of inconsistency in that the default parameter for `currentdate` is `False` for graft, and `None` for the rest. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-January/126767.html Differential Revision: https://phab.mercurial-scm.org/D6841
Mon, 09 Sep 2019 13:25:00 -0400 hgweb: fix websub regex flag syntax on Python 3
Connor Sheehan <sheehan@mozilla.com> [Mon, 09 Sep 2019 13:25:00 -0400] rev 42923
hgweb: fix websub regex flag syntax on Python 3 The `websub` config section for hgweb is broken under Python 3 when using regex flags syntax (ie the optional `i` in the example from `hg help config.websub`: patternname = s/SEARCH_REGEX/REPLACE_EXPRESSION/[i] Flags are pulled out of the specified byte-string using a regular expression, and uppercased. The flags are then iterated over and passed to the `re` module using `re.__dict__[item]`, to get the object attribute of the same name from the `re` module. So on Python 2 if the `il` flags are passed, this transition looks like: `'il'` -> `'IL'` -> `'I'` -> `re.__dict__['I']` -> `re.I` However on Python 3, these are bytes objects. When we iterate over a bytes object in Python 3, instead of getting the individual characters in the string as string objects of length one, we get the integer \ value corresponding to that byte. So the same transition looks like: `b'il'` -> `b'IL'` -> `73` -> `re.__dict__[73]` -> `KeyError` This commit fixes the type mismatch by converting the bytes to a system string before iterating over each element to pass to `re`. The transition will now look like: `b'il'` -> `u'IL'` -> `u'I'` -> `re.__dict__[u'I']` -> `re.I` In addition we expand `test-websub.t` to cover the regex flag case (for both the `websub` section and `interhg`). Differential Revision: https://phab.mercurial-scm.org/D6788
Mon, 09 Sep 2019 17:26:17 -0400 merge with stable
Augie Fackler <augie@google.com> [Mon, 09 Sep 2019 17:26:17 -0400] rev 42922
merge with stable
Mon, 09 Sep 2019 12:56:17 -0700 relnotes: we now require `sh` to support $(command) syntax to run test suite
Martin von Zweigbergk <martinvonz@google.com> [Mon, 09 Sep 2019 12:56:17 -0700] rev 42921
relnotes: we now require `sh` to support $(command) syntax to run test suite For example, Solaris before version 11 had /bin/sh pointing to the old Bourne Shell (which doesn't support $(command) syntax). Differential Revision: https://phab.mercurial-scm.org/D6833
Sun, 08 Sep 2019 20:09:31 -0400 doc: fix up confusing doc comment
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 08 Sep 2019 20:09:31 -0400] rev 42920
doc: fix up confusing doc comment Differential Revision: https://phab.mercurial-scm.org/D6829
Fri, 06 Sep 2019 23:15:52 -0700 strip: fix bug with treemanifests and unordered linkrevs
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Sep 2019 23:15:52 -0700] rev 42919
strip: fix bug with treemanifests and unordered linkrevs This is the treemanifest version of f45f7390c1c5 (strip: calculate list of extra nodes to save and pass it to changegroupsubset, 2008-01-19). Differential Revision: https://phab.mercurial-scm.org/D6795
Fri, 06 Sep 2019 23:10:28 -0700 repair: extract a helper for generating all manifest revlogs
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Sep 2019 23:10:28 -0700] rev 42918
repair: extract a helper for generating all manifest revlogs We'll need to walk the manifest revlogs also to figure out which manifests have linkrevs out of order (for fixing the bug shown in the previous patch). By the way, perhaps it would be more efficient in many cases to find only the relevant directory manifest revlogs based on the files instead of walking the entire store, but that can be changed later. Differential Revision: https://phab.mercurial-scm.org/D6794
Fri, 06 Sep 2019 22:53:14 -0700 tests: show broken strip with treemanifests and unordered linkrevs
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Sep 2019 22:53:14 -0700] rev 42917
tests: show broken strip with treemanifests and unordered linkrevs This is the treemanifest version of issue764. Differential Revision: https://phab.mercurial-scm.org/D6793
Mon, 17 Dec 2018 11:06:26 -0800 tests: split out manifest case from test-strip-cross.t
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Dec 2018 11:06:26 -0800] rev 42916
tests: split out manifest case from test-strip-cross.t The manifest case was added on after the other cases, in d67cfe0d4714 (test-strip-cross: test handling of linkrev crosses in the manifest, 2008-01-20). I think it's easier to read and modify if it's separated. Differential Revision: https://phab.mercurial-scm.org/D6792
Mon, 17 Dec 2018 11:09:05 -0800 tests: don't log manifest-file in test-strip-cross.t
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Dec 2018 11:09:05 -0800] rev 42915
tests: don't log manifest-file in test-strip-cross.t I'm confident that the file is there only to help produce a certain manifest log; there is nothing special about the file's filelog itself. (And there already is a `hg debugindex --manifest` call higher up in the file that shows the crossed linkrevs.) Differential Revision: https://phab.mercurial-scm.org/D6791
Mon, 17 Dec 2018 10:27:00 -0800 tests: use positive revision numbers in test-strip-cross.t
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Dec 2018 10:27:00 -0800] rev 42914
tests: use positive revision numbers in test-strip-cross.t It took me a long time to realize that '-r -1' was pulling revision -1 because I didn't even notice the minus sign until I tried changing the revision number. The order of arguments doesn't matter, so I changed from decreasing order to increasing while at it. Differential Revision: https://phab.mercurial-scm.org/D6790
Thu, 05 Sep 2019 21:09:58 -0700 automation: implement "publish-windows-artifacts" command
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Sep 2019 21:09:58 -0700] rev 42913
automation: implement "publish-windows-artifacts" command The new command and associated functionality can be used to automate the publishing of Windows release artifacts. It supports uploading wheels to PyPI (using twine) and copying the artifacts to mercurial-scm.org and updating the latest.dat file to advertise them via the website. I ran `automation.py publish-windows-artifacts 5.1.1` and it appeared to "just work." But the real test will be to do this on the next release... Differential Revision: https://phab.mercurial-scm.org/D6786
Thu, 05 Sep 2019 21:08:35 -0700 automation: upgrade to latest packages in requirements.txt
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Sep 2019 21:08:35 -0700] rev 42912
automation: upgrade to latest packages in requirements.txt Let's stay modern. Differential Revision: https://phab.mercurial-scm.org/D6785
Thu, 15 Aug 2019 14:53:27 -0400 localrepo: push manifestlog and changelog construction code into store
Augie Fackler <augie@google.com> [Thu, 15 Aug 2019 14:53:27 -0400] rev 42911
localrepo: push manifestlog and changelog construction code into store This feels substantially more appropriate, as the store is actually the layer with knowledge of how to handle this storage. I didn't move the caching decorators for now because that's going to require some more involved work, and this unblocks my current experimentation. Differential Revision: https://phab.mercurial-scm.org/D6732
Sat, 07 Sep 2019 12:49:33 +0200 notify: add option for deterministic message-id generation
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Sep 2019 12:49:33 +0200] rev 42910
notify: add option for deterministic message-id generation Copied from email by durin42: > Pierre-Yves asked offline why I asked a new option for this and why it > is not the default. Message-Id is supposed to be unique world-wide and > while it is desirable to have a deterministic mechanism for them for > creating follow-up emails, it needs organisational control for ensuring > the uniqueness. Differential Revision: https://phab.mercurial-scm.org/D6824
Sat, 07 Sep 2019 23:20:11 -0400 uncommit: add options to update to the current user or current date
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Sep 2019 23:20:11 -0400] rev 42909
uncommit: add options to update to the current user or current date These are also from the evolve extension's version of uncommit. I tried adding validation that both forms of user or date can't be specified at the same time, but that fails because these show up in `opts` with a None value whether or not the option was given on the command line. Presumably that means the conditional in `resolvecommitoptions` could be simplified. But this is how both evolve and MQ handle it. Differential Revision: https://phab.mercurial-scm.org/D6828
Sat, 07 Sep 2019 13:44:29 -0400 uncommit: add support to modify the commit message and date
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Sep 2019 13:44:29 -0400] rev 42908
uncommit: add support to modify the commit message and date Currently, the evolve extension's version of this command supports it. Differential Revision: https://phab.mercurial-scm.org/D6827
Fri, 14 Jun 2019 17:50:04 +0100 run-tests: add a dedicated 'isoptional' function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:50:04 +0100] rev 42907
run-tests: add a dedicated 'isoptional' function This is clearer than repeated manual call to to 'endswith'. (This is a gratuitous cleanup that I made while investigating a bug).
Fri, 14 Jun 2019 17:39:16 +0100 run-tests: remove the artificial indentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:39:16 +0100] rev 42906
run-tests: remove the artificial indentation
Fri, 14 Jun 2019 17:37:04 +0100 run-tests: extract a `process_out_line` from the main function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:37:04 +0100] rev 42905
run-tests: extract a `process_out_line` from the main function The main function doing line comparison is quite complex. Slicing it in smaller piece should clarify it. To avoid a huge diff, the code is kept at the same indentation. We'll re-indent in the next changesets. (This is a gratuitous cleanup that I made while investigating a bug).
Sun, 08 Sep 2019 10:08:41 +0200 run-tests: extract a `process_cmd_line` from the main function
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 10:08:41 +0200] rev 42904
run-tests: extract a `process_cmd_line` from the main function The main function doing line comparison is quite complex. Slicing it in smaller piece should clarify it. (This is a gratuitous cleanup that I made while investigating a bug).
Sun, 08 Sep 2019 09:42:53 +0200 changegroup: move message about added changes to transaction summary
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 09:42:53 +0200] rev 42903
changegroup: move message about added changes to transaction summary Before that, applying multiple changegroups in the same transaction issued the message multiple time. This result in a confusing output: adding changesets adding manifests adding file changes added 32768 changesets with 60829 changes to 2668 files adding changesets adding manifests adding file changes added 8192 changesets with 16885 changes to 1553 files adding changesets adding manifests adding file changes added 1020 changesets with 1799 changes to 536 files adding changesets adding manifests ... Instead, we now only issue the message once at the end of the transaction, summing up all added changesets, changes and files. The line is identical, but happens sightly later in the output. There are other suboptimal behavior around issue multiple changegroup (eg: progress bar). We'll cover them later. This impact of lot of test as one would expect, but a two pass check show they are just the order change we expected. To deal with "under the hood" bundle application by internal code, we had to take a slightly hacky move. We could clean that up with a more official way to enter "under the hood" section, however I want to keep this series simple to get it landed. This kind of change have a very high bit rot rate since it impact a lot of test output.
Sun, 08 Sep 2019 01:02:34 +0200 sshserver: flush stream after command dispatch
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 01:02:34 +0200] rev 42902
sshserver: flush stream after command dispatch I am not sure why this is not working as expected, but without this client might not see some important output. Without this patch moving some output at transaction closing time makes it disapear for ssh client in various sitaution.
(0) -30000 -10000 -3000 -1000 -300 -100 -96 +96 +100 +300 +1000 +3000 tip