Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 07 Aug 2019 19:18:20 +0530] rev 42728
config: fix fm.data() handling of defaultvalue
This is a follow-up patch to rHG51a2e3102db2. This moves
`fm.data()` out of the if block in `commands.config()`.
Differential Revision: https://phab.mercurial-scm.org/D6720
Navaneeth Suresh <navaneeths1998@gmail.com> [Sat, 03 Aug 2019 12:14:34 +0530] rev 42727
config: remove pycompat.bytestr() for defaultvalue
This is a follow-up patch to 51a2e3102db2. This removes
`pycompat.bytestr` to preserve `None` in `commands.config()`.
Differential Revision: https://phab.mercurial-scm.org/D6712
Navaneeth Suresh <navaneeths1998@gmail.com> [Sat, 27 Jul 2019 12:19:51 +0530] rev 42726
unshelve: clear shelvedstate and _finishunshelve() on partial unshelve
On a partial unshelve, `shelvedstate` was not cleared and `_finishunshelve()`
was not called. Ideally, these should be called on this case. This patch makes
`shelvedstate` to delete after a successful partial unshelve and calls
`_finishunshelve()` in the same case.
Differential Revision: https://phab.mercurial-scm.org/D6708
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 25 Jul 2019 22:01:15 +0530] rev 42725
unshelve: delete shelvedstate after a successful unshelve --continue
`unshelve --continue` was preventing the deletion of `shelvedstate` on
a partial `unshelve`. Ideally, `shelvedstate` should be deleted after
a successful `unshelve`. Now, the behavior of `unshelve --continue`
will be as follows in interactive mode:
1] The user tried to `unshelve` changes interactively but, ran into
conflicts.
2] They resolved the conflicts and triggered `unshelve --continue`
but, unshelved changes partially.
3] Now, on trying to do `unshelve --continue` again will abort as
the last `unshelve` was successful and we are deleting the
`shelvedstate`.
4] If they want to unshelve the remaining shelved change, they
need to trigger `unshelve` without `--continue`.
Differential Revision: https://phab.mercurial-scm.org/D6694
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 18:15:27 +0530] rev 42724
unshelve: handle stripping changesets on interactive mode
On interactive mode, changesets on `nodestoremove` should be
stripped regardless of the shelve is partial or not. This patch
modifies `unshelvecontinue()` to do that.
Differential Revision: https://phab.mercurial-scm.org/D6686
Raphaël Gomès <rgomes@octobus.net> [Tue, 06 Aug 2019 14:54:25 +0200] rev 42723
byteify-strings: add --version argument
This is indispensable for automated tools to detect changes in behavior.
Raphaël Gomès <rgomes@octobus.net> [Tue, 06 Aug 2019 14:49:30 +0200] rev 42722
byteify-strings: add space in special comments to silence flake8 error
This is done soon enough that nobody has had the time to use this feature yet.
Anton Shestakov <av6@dwimlabs.net> [Thu, 18 Jul 2019 17:10:38 +0800] rev 42721
revset: drop argument when it's None
getstack's definition is `getstack(repo, rev=None)`, so providing None
explicitly is unnecessary. Moreover, when x is not None, it's definitely not a
revision but a part of a parsed tree of revset arguments.
Differential Revision: https://phab.mercurial-scm.org/D6707
Anton Shestakov <av6@dwimlabs.net> [Thu, 18 Jul 2019 17:07:34 +0800] rev 42720
stack: remove unnecessary reverse() predicate
Stack already sorts revisions, so no need to do it twice.
This change was a part of D2400, which didn't land for other reasons. See also
D2399, where this change was suggested.
Differential Revision: https://phab.mercurial-scm.org/D6706
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 16:47:49 -0700] rev 42719
automation: increase root volume size on Linux
It is close to full in the AMI. I actually ran out of space running
tests without increasing the volume size!
Differential Revision: https://phab.mercurial-scm.org/D6716
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 16:03:11 -0700] rev 42718
automation: install Rust in Linux environment
This will install Rust 1.31.1, 1.34.2, and whatever stable is at
the time the install runs. We install 1.31.1 as our minimum supported
Rust version (I think that's what we're currently targeting) and
1.34 because that's what Debian 10 is shipping.
Differential Revision: https://phab.mercurial-scm.org/D6715
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 14:17:41 -0700] rev 42717
automation: update packages in requirements files
We like keeping up to date. The content of the autogenerated files
changed slightly because I used a newer version of `pip-compile`
than what was used previously.
Differential Revision: https://phab.mercurial-scm.org/D6714
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 14:04:31 -0700] rev 42716
automation: install latest Python versions
This required bumping the pyenv commit so the new versions are
available.
Differential Revision: https://phab.mercurial-scm.org/D6713
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Aug 2019 03:15:58 +0200] rev 42715
upgrade: introduce the internal code for revlog cloning selection
For now we still clone every single revlogs but all the selection mechanism is
now in place in the lower layer.
The next changesets will introduce the user interface part of the selection.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 30 Jul 2019 19:58:44 +0200] rev 42714
upgrade: introduce a _copyrevlog method
This function copies a revlog from the old store to the new one, without
re-adding all deltas manually. This will eventually save a lot of time when some
revlog does not needs any conversions.
Code actually using this will be introduced in later changesets.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 27 Jul 2019 19:25:47 +0200] rev 42713
upgrade: rename `_copyrevlogs` to `_clonerevlogs`
The underlying revlog method is named `clone`, keeping the naming consistent
seems clearer. This is motivated to clarify the difference with an (upcoming)
function that simply copy revlog files as is.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 27 Jul 2019 19:58:17 +0200] rev 42712
upgrade: walk the source store file only once
I don't expect this to have a significant performance impact, but it seems
simpler and saner to do the operation only once and to keep the result around.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 14:22:49 +0100] rev 42711
upgrade: always use full text if "full-add" mode is enable
We should not be using a delta since the goal is to perform a full addition from
scratch in all cases.
Without this patch, `hg debugupgraderepo --optimize re-delta-fulladd --run` can
crash.
Raphaël Gomès <rgomes@octobus.net> [Sun, 04 Aug 2019 22:14:26 +0200] rev 42710
byteify-strings: fix misalignment with multi-line parenthesis
This improves the current fix to also take into account cases where the last
line ended on the opening `(`, `[` or `{` and adds a regression test.
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 16:54:02 +0200] rev 42709
byteify-strings: add test for byteify-strings.py
This tests the basic features expected from this script, some cases may not
be covered yet.
A future patch will demonstrate an issue with multi-line `(`, `[` and `{`
alignment and propose a fix.
Yuya Nishihara <yuya@tcha.org> [Sun, 04 Aug 2019 20:59:21 +0900] rev 42708
merge with stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 16:17:02 +0200] rev 42707
byteify-strings: add cli argument to handle `attr*()` when they are methods
Certain code bases have useful utils that wrap the builtin functions, and are
called like `util.setattr`.
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 16:14:00 +0200] rev 42706
byteify-strings: simplify default value for `--treat-as-kwargs`
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 10:18:22 +0200] rev 42705
byteify-strings: add --treat-as-kwargs argument to handle kwargs-like objects
This argument will help extensions move to Python 3 as keyword arguments
should not be byte-prefixed. Most of the time, code bases will call this
object `kwargs`, but other conventions exist like `opts`, so it should make
sense to allow for custom names.
This is a best effort solution that does minimal static checking; cases like
`options = [o for o in ('a', 'b', 'c') if kwargs.get(o)]`
and other just as complicated will not be detected.
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 10:10:23 +0200] rev 42704
byteify-strings: add helpers to check for item access or method call
These helpers will be used in a future patch, split for ease of review.
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 09:55:32 +0200] rev 42703
byteify-strings: add support for ignore comments
Our simple token analysis is sometimes not clever enough, we need to be able
to turn off our script for parts of the code.
This change introduces three special comments:
- `#no-py3-transform` to tell `byteify-strings` ignore the next line
- `#py3-transform: off` to ignore everything until the end of the file
- `#py3-transform: on` to stop ignoring
The last two can be particularly useful within Python 2/3 compatibility files.
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 09:48:13 +0200] rev 42702
byteify-strings: handle triple quoted strings if they are not docstrings
As with anything in this script, this is a best effort approach. Most of the
time, when a triple quoted string is assigned to something, it's not a
docstring.
Raphaël Gomès <rgomes@octobus.net> [Fri, 02 Aug 2019 09:44:11 +0200] rev 42701
byteify-strings: handle multi-line strings in _ensuresysstr
The current implementation did not handle calls like
`repo.ui.log("first line"
"other line")`
correctly.
Danny Hooper <hooper@google.com> [Wed, 22 May 2019 16:22:06 -0700] rev 42700
fix: run fixer tools in the repo root as cwd so they can use the working copy
This lets fixer tools do things like find configuration files, with the caveat
that they'll only see the version of that file in the working copy, regardless
of what revisions are being fixed.
Differential Revision: https://phab.mercurial-scm.org/D6440
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 01 Aug 2019 22:03:52 +0530] rev 42699
config: add defaultvalue template keyword
This patch tries to fix one of the issues mentioned in issue6014.
This adds a new `defaultvalue` template keyword to be used with
`hg showconfig` to get the default value of the config item.
Differential Revision: https://phab.mercurial-scm.org/D6704
Augie Fackler <augie@google.com> [Thu, 01 Aug 2019 12:23:07 -0400] rev 42698
merge with stable
Raphaël Gomès <rgomes@octobus.net> [Tue, 23 Jul 2019 11:12:36 +0200] rev 42697
module-policy: update rust extension import to use the new module policy
Differential Revision: https://phab.mercurial-scm.org/D6677
Martin von Zweigbergk <martinvonz@google.com> [Sun, 21 Jul 2019 07:59:16 -0700] rev 42696
transaction: leave unfinished without crashing when not properly released
I think the transaction.__del__ is there just as a last resort in case
we (or an extension) forgot to release the transaction. When that
happens, the repo can (or will on Python 3?) get deleted before the
transaction. This leads to a crash in test-devel-warnings.t on Python
3 because we tried to access repo.dirstate, where repo was retried
from a weak reference. There's not much we can do here, but let's at
least avoid the crash. The user will have run `hg recover` afterwards
regardless.
Differential Revision: https://phab.mercurial-scm.org/D6664
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 30 Jul 2019 21:36:15 +0530] rev 42695
unshelve: add abort on using continue and interactive together
`unshelve --continue --interactive` will not work as expected by the
user as the mode of in-progress unshelve is preserved and cannot be
overwritten. This patch makes `unshelve` to throw an error on using
both `--continue` and `--interactive` together with `unshelve`.
Differential Revision: https://phab.mercurial-scm.org/D6703
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 29 Jul 2019 13:22:52 +0300] rev 42694
py3: add one more test to list of passing tests
Found by buildbot.
Differential Revision: https://phab.mercurial-scm.org/D6702
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 29 Jul 2019 13:25:05 +0300] rev 42693
tests: sort imports in test-bookmarks-corner-case.t
test-check-module-imports.t breaks on py3 without this change.
Differential Revision: https://phab.mercurial-scm.org/D6701
Danny Hooper <hooper@google.com> [Fri, 26 Jul 2019 10:47:06 -0700] rev 42692
fix: add some new test cases
These cover a couple of behaviors we were testing at Google that weren't
covered here before.
Differential Revision: https://phab.mercurial-scm.org/D6698
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 00:44:12 +0530] rev 42691
unshelve: store information about interactive mode in shelvedstate
This is a follow-up patch to 5162753c4c14. This makes `unshelve`
stores the information about interactive mode on conflicts.
Differential Revision: https://phab.mercurial-scm.org/D6679
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 18:20:01 +0530] rev 42690
unshelve: create a matcher only if required on creating unshelve ctx
Differential Revision: https://phab.mercurial-scm.org/D6687
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 18:10:50 +0530] rev 42689
unshelve: changes how date is set on interactive mode
On an interactive unshelve, the remaining changes are shelved again
for later. This patch modifies the date of remaining shelved change
to the time of interactive shelve.
Differential Revision: https://phab.mercurial-scm.org/D6685
Navaneeth Suresh <navaneeths1998@gmail.com> [Wed, 24 Jul 2019 09:06:25 +0530] rev 42688
unshelve: unify logic around creating an unshelve changeset
This is a follow-up patch to 5162753c4c14 on addressing reviews
on the commit. This unifies the logic around creating an unshelve
changeset.
Differential Revision: https://phab.mercurial-scm.org/D6683
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:19:00 -0700] rev 42687
fix: ignore fixer tool configurations that are missing patterns
This is to prevent a crash under the same circumstances.
This is also to avoid data loss due to accidental application of a fixer tool
to all files, if the matching logic somehow changed to that effect. Affecting
all files until otherwise configured would be dangerous, and not very useful.
We shouldn't abort because there may be other fixers, and it may still be
useful to run them without having to adjust configuration. A user might not
feel confident in changing configs, for example.
Differential Revision: https://phab.mercurial-scm.org/D6693
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:21:12 -0700] rev 42686
fix: add a test case around the effect of cwd on pattern matching
This was not covered by previous tests. It is related to a regression
encountered at Google due to misconfiguration of [fix].
Differential Revision: https://phab.mercurial-scm.org/D6692
Danny Hooper <hooper@google.com> [Wed, 24 Jul 2019 16:22:45 -0700] rev 42685
fix: remove support for :fileset sub-config in favor of :pattern
Differential Revision: https://phab.mercurial-scm.org/D6691
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 15:01:28 -0400] rev 42684
fsmonitor: add support for extra `hg debuginstall` data
This might make some things easier to debug, and for default bug
report templates it'll help collect more data from users all at
once. I don't actually need fsmonitor in our bug reports (we don't use
it), but this demonstrates the utility of the preceding patches
without having to add new things to core.
Differential Revision: https://phab.mercurial-scm.org/D6682
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 14:37:51 -0400] rev 42683
debugcommands: add support for extensions adding their own debug info
We've had a couple of cases where it'd be handy at Google to add data
to `hg debuginstall`'s output. We've kludged around that at various
times, but it seems reasonable to let extensions add their own data
here so extension maintainers can get useful extra data.
Differential Revision: https://phab.mercurial-scm.org/D6681
Augie Fackler <augie@google.com> [Tue, 23 Jul 2019 14:36:38 -0400] rev 42682
fsmonitor: refactor watchmanclient.client to accept ui and repo path
This will make my next patch simpler.
Differential Revision: https://phab.mercurial-scm.org/D6680
Augie Fackler <raf@durin42.com> [Wed, 02 Oct 2019 12:20:36 -0400] rev 42681
Added signature for changeset 181e52f2b62f
Augie Fackler <raf@durin42.com> [Wed, 02 Oct 2019 12:20:35 -0400] rev 42680
Added tag 5.1.2 for changeset 181e52f2b62f
Anton Shestakov <av6@dwimlabs.net> [Fri, 20 Sep 2019 23:31:03 +0700] rev 42679
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.
Anton Shestakov <av6@dwimlabs.net> [Wed, 18 Sep 2019 17:53:10 +0700] rev 42678
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].
Ian Moody <moz-ian@perix.co.uk> [Sat, 07 Sep 2019 14:35:21 +0100] rev 42677
phabricator: don't abort if property writing fails during amending
Currently if one of the writediffproperty calls fails due to network issues
during the amending of commit messages to include the Diff. Rev. line, the
transaction is aborted and rolled back. This means that the associations
between the commits and the DREVs are lost for any already amended commits
because the removal of the local tags isn't covered by the rollback.
Differential Revision: https://phab.mercurial-scm.org/D6835
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 09 Sep 2019 17:32:21 +0200] rev 42676
merge: respect parents order when using `graft` on a merge
The previous code did not record the index of the replaced parent. It was always
using the "graft" destination as `p1`. This could switch parents order in some
situation (eg: some of the evolve evolving merge case). Recording and using the
information fixes the issue in evolve.
We are not aware of core commands calling graft in that fashion, so we could not
build a simple test case for it using core commands.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 14:51:18 +0200] rev 42675
tests: register test-merge-combination.t as small but slow
run-tests.py use file size as an heuristic for test run time. The new
`test-merge-combination.t` is a small file that do a lot of processing. As a
result it tend to be scheduled really late but delay the full test run by a lot.
On an example test run, the one-before-last test completed 279s after the start
of the run, while `test-merge-combination.t` finished 355s after it. A 76s
delay. This delay can be avoided since `test-merge-combination.t` only got started
175s after the start of the run.
Julien Cristau <jcristau@debian.org> [Fri, 06 Sep 2019 11:48:49 +0200] rev 42674
test: allow different result for zstd compression (issue6188)
test-repo-compengines fails on big-endian due to different file size,
but the repo doesn't seem broken, so allow both sizes.
Differential Revision: https://phab.mercurial-scm.org/D6787
Augie Fackler <raf@durin42.com> [Thu, 05 Sep 2019 14:08:22 -0400] rev 42673
Added signature for changeset a4e32fd539ab
Augie Fackler <raf@durin42.com> [Thu, 05 Sep 2019 14:08:20 -0400] rev 42672
Added tag 5.1.1 for changeset a4e32fd539ab
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 25 Aug 2019 09:00:26 -0700] rev 42671
python-zstandard: apply big-endian fix (issue6188)
This is a port of commit d4baf1f95b811f40773f5df0d8780fb2111ba6f5
from the upstream project to fix python-zstandard on 64-bit big-endian.
Navaneeth Suresh <navaneeths1998@gmail.com> [Sat, 17 Aug 2019 01:49:28 +0530] rev 42670
exchange: abort on pushing bookmarks pointing to secret changesets (issue6159)
Until now, if there is a bookmark points to a changeset which is in secret
phase, hg will push the bookmark, but not the changeset referenced by that
bookmark. This leaves the server bookmarks in a bad state, because that
bookmark now points to a revision that does not exist on the server. This
patch makes hg to abort on such cases.
Differential Revision: https://phab.mercurial-scm.org/D6731
Navaneeth Suresh <navaneeths1998@gmail.com> [Sun, 18 Aug 2019 02:47:32 +0530] rev 42669
tests: add test to demonstrate issue6159
Differential Revision: https://phab.mercurial-scm.org/D6740
Anton Shestakov <av6@dwimlabs.net> [Sun, 25 Aug 2019 19:46:24 +0700] rev 42668
packaging: add Bullseye, remove Jessie
Jessie is oldoldstable now, and Bullseye is going to be the next stable (now
testing). We're continuing to support the current oldstable, stable and testing
releases.
Differential Revision: https://phab.mercurial-scm.org/D6762
Anton Shestakov <av6@dwimlabs.net> [Sun, 25 Aug 2019 19:38:09 +0700] rev 42667
packaging: add Cosmic and Disco, remove Trusty and Artful
- Trusty was publicly supported until 2019-04-30
- Artful was publicly supported until 2018-07-19
- Cosmic was publicly supported until 2019-07-18
- Disco will be publicly supported until 2020-01
Cosmic is officially out-of-date, but since it still may be in use, and because
we didn't add it when it first came out, I think it would be nice to support it
until the next time somebody decides to update this list of Ubuntu releases.
Differential Revision: https://phab.mercurial-scm.org/D6761
Raphaël Gomès <rgomes@octobus.net> [Wed, 21 Aug 2019 17:56:50 +0200] rev 42666
makefile: run Rust tests if cargo is installed
While no particular minimum toolchain version is targeted as of yet, this
serves as a first step to make more people/machines run the Rust tests.
Augie Fackler <augie@google.com> [Fri, 16 Aug 2019 15:41:53 +0300] rev 42665
tests: use `tr -d` and not `tr --delete` as the latter is absent on BSD tr(1)
Differential Revision: https://phab.mercurial-scm.org/D6729
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 12 Aug 2019 14:00:19 -0400] rev 42664
fncache: make debugrebuildfncache not fail on broken fncache
The code reading the fncache changed in 5.0, to complain if the file
is not \n terminated. This makes apparent the fact that the fncache
gets corrupted.
Make it possible to recover, instead of having `hg
debugrebuildfncache` failing by saying `(run hg debugrebuildfncache)`.
The corruption itself is most likely due to hg not using fsync in
general, and so various bad things can happen. Here, the reported
problems happened when running out of disk space. So I suspect that
because the fncache is much bigger than the average commit/pull, when
running out of disk space, the bulk of the pull may succeed, but the
new fncache may get half-written and still renamed into place.
Differential Revision: https://phab.mercurial-scm.org/D6722
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 12 Aug 2019 13:22:27 -0400] rev 42663
fncache: show that debugrebuildfncache is partly broken
Differential Revision: https://phab.mercurial-scm.org/D6721
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 09 Aug 2019 13:11:27 +0200] rev 42662
test: further fixes to matching for run-tests.py bug
The fix in bac24a8a095a did not fix the full issue, because the extra number
also eat some of the separator space. Since we are already matching arbitrary
number of space, we easily fix the matching.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 11:06:13 +0200] rev 42661
demandimport: explicitly declare `_session` at the module level
The `_session` module level variable is set within a function using the `global`
keyword. This confuses my `test-check-pyflakes.t`. Explicitly declaring the
variable at the top level solves the issue (and seems absolutely reasonable).
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 10:55:06 +0200] rev 42660
tests: give more room for slowness in test-run-tests.t
The test expected any run-test.py run to end in less than 10 seconds. On slower
loaded CI machine, this gets slower than that. We give a bit more room to the
regexp.
Martin von Zweigbergk <martinvonz@google.com> [Thu, 01 Aug 2019 11:02:12 -0700] rev 42659
relnotes: copy "next" to "5.1" and clear "next"
To avoid merge conflicts, we want to avoid modifying the file on
multiple branches in parallel. This patch is therefore meant to be
applied to the stable branch and then quickly be merged to default (at
least before edits are made to relnotes/next there).
Another option would have been to copy the file on the stable branch
and to clear it on the default branch. However, that still results in
conflicts if the copy is edited on the stable branch (Mercurial would
try to apply the changes from the default branch to it).
We could also delete the file in one commit and recreate it in another
commit. However, Mercurial is quite inconsistent in what it considers
a break in history (see test-copies-unrelated.t), so I'd like to avoid
that.
Differential Revision: https://phab.mercurial-scm.org/D6705
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 12:13:51 -0700] rev 42658
automation: push changes affecting .hgtags
When I went to build the 5.1 tag using the in-repo automation, the
automatic version calculation failed to deduce the clean 5.1 version
string because we had only pushed the changeset corresponding to the 5.1
tag and not the changeset containing the 5.1 tag. So from the
perspective of the remote repo, the 5.1 tag didn't exist yet and
automatic version deduction failed.
This commit changes the `hg push` to also push all changesets affecting
the .hgtags file, ensuring the remote has up-to-date tags information.
I tested this by creating a local draft changeset with a dummy tag
value on a different DAG head and instructed the automation to build
a revision that didn't have this change to .hgtags. The tag was
successfully pushed and the built package had a version number
incorporating that tag.
Sending this to stable so the 5.1.1 automation hopefully "just works."
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 21 Jun 2019 03:50:40 +0200] rev 42657
bookmarks: actual fix for race condition deleting bookmark
This is a simple but efficient fix to prevent the issue tested in
`test-bookmarks-corner-case.t`. It might be worth pursuing a more generic
approach where filecache learn to depend on each other, but that would not be
suitable for stable.
The issue is complicated enough that I documented the race and its current
solution as inline comment. See this comment for details on the fix.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Aug 2019 16:22:47 +0200] rev 42656
strip: access bookmark before getting a reference to changelog
Bookmark access might invalidate the current changelog (to make sure both are in
a reasonable synchronisation state). So we should grab the reference to
changelog after we access bookmark. Otherwise we risk using a dead object for
the whole strip process.
(note: this dead object business probably requires a new layers of checking)
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Aug 2019 15:59:52 +0200] rev 42655
test: use a more verbose output in the test
While debugging some test failure, I released the test never checks if the
relevant changesets were preserved. So I am updating the test from `hg parents`
usage to `hg log -G` with a special template. This increase the area covered by
the test and clarify the test failures.
Augie Fackler <raf@durin42.com> [Thu, 01 Aug 2019 12:14:52 -0400] rev 42654
Added signature for changeset e91930d712e8
Augie Fackler <raf@durin42.com> [Thu, 01 Aug 2019 12:14:50 -0400] rev 42653
Added tag 5.1 for changeset e91930d712e8
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 28 Jul 2019 18:32:31 -0700] rev 42652
automation: execute powershell when connecting
For some reason, the ability to execute PS scripts appears to
come online after the ability to execute regular command scripts.
This is creating race conditions when connecting to instances
resulting in our wait_for_winrm() returning before PS is available
leading to an exception being thrown in other code.
Let's change the client connection code to execute a minimal
PS script so we can try to trap the exception in wait_for_winrm().
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 28 Jul 2019 18:16:08 -0700] rev 42651
automation: allow exit code of 1 for `hg push`
`hg push` exits 1 for no-ops. No-op pushes should be fine in the
context of automation.
Yuya Nishihara <yuya@tcha.org> [Thu, 25 Jul 2019 21:28:29 +0900] rev 42650
curses: do not setlocale() at import time (issue5261)
setlocale() can break date formatting/parsing functions because they are
locale dependent. We should avoid doing setlocale() as possible.
This patch moves setlocale() just before curses.wrapper(), which function
is documented to "initialize curses." I don't know the details about the
curses initialization, but I *think* this would work as well.
Maybe we can extract a curses setup function later.
https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-February/128788.html
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 19:10:59 -0700] rev 42649
contrib: install Python 3.8b2 instead of 3.8a2
Let's install the most recent Python 3.8 distribution.
Differential Revision: https://phab.mercurial-scm.org/D6674
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 19:06:20 -0700] rev 42648
automation: make Windows base image name configurable
Since automation broke in the middle of the 5.0 release cycle,
there's a good chance it will break again in the future. While
a robust solution might be to search for all available images and
choose the newest one, it does seem useful to be able to explicitly
choose the name of the image to find and use so users can opt in
to using a different image.
This commit implements that functionality.
Differential Revision: https://phab.mercurial-scm.org/D6673
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 18:55:52 -0700] rev 42647
automation: extract strings to constants
Differential Revision: https://phab.mercurial-scm.org/D6672
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 18:52:58 -0700] rev 42646
automation: use newer Windows base image
It looks like the old base image disappeared. Let's use a newer
image that exists today.
Differential Revision: https://phab.mercurial-scm.org/D6671
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jul 2019 17:44:19 -0700] rev 42645
copies: fix crash on in changeset-centric tracing from commit to itself
When we trace copies from a changeset to itself, the "work" queue ends
up empty and we hit the "assert False" after it.
It was only the last of the three added tests that failed before this
patch. That is because the other two cases have fast paths, so
_committedforwardcopies() is never reached.
Differential Revision: https://phab.mercurial-scm.org/D6675
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 23 Jul 2019 12:03:24 +0530] rev 42644
unshelve: add help text on --interactive in verbose mode
This is a follow-up patch to rHG9eace8d6d537. This modifies the
help text of unshelve in verbose mode to mention the details
about `--interactive` flag.
Differential Revision: https://phab.mercurial-scm.org/D6676
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 22 Jul 2019 06:33:11 -0400] rev 42643
amend: stop committing unrequested file reverts (issue6157)
Differential Revision: https://phab.mercurial-scm.org/D6667
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 22 Jul 2019 06:33:00 -0400] rev 42642
amend: add a test for a simplified version of issue6157
Differential Revision: https://phab.mercurial-scm.org/D6666
Martin von Zweigbergk <martinvonz@google.com> [Sun, 21 Jul 2019 18:04:05 -0700] rev 42641
py: error out if a "skip" character was given with non-dict to util.dirs()
util.dirs() keeps track of the directories in its input collection. If
a "skip" character is given to it, it will assume the input is a
dirstate map and it will skip entries that are in the given "skip"
state. I think this is used only for skipping removed entries ("r") in
the dirtate. The C implementation of util.dirs() errors out if it was
given a skip character and a non-dict was passed. The pure
implementation simply ignored the request skip state. Let's make it
easier to discover bugs here by erroring out in the pure
implementation too. Let's also switch to checking for the dict-ness,
to make the C implementation (since that's clearly been sufficient for
many years). This last change makes test-issue660.t pass on py3 in
pure mode, since the old check was for existence of iteritems(), which
doesn't exist on py3.
Differential Revision: https://phab.mercurial-scm.org/D6669
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jul 2019 09:55:05 -0700] rev 42640
py3: fix incorrect fix of test-setdiscovery.t in eb27d9eee2cc
Both places should have been changed from 185 to 187.
Differential Revision: https://phab.mercurial-scm.org/D6668
Augie Fackler <raf@durin42.com> [Mon, 22 Jul 2019 14:08:56 -0400] rev 42639
Added signature for changeset e386b5f4f836
Augie Fackler <raf@durin42.com> [Mon, 22 Jul 2019 14:08:54 -0400] rev 42638
Added tag 5.1rc0 for changeset e386b5f4f836
Augie Fackler <augie@google.com> [Mon, 22 Jul 2019 14:00:33 -0400] rev 42637
merge default into stable for 5.1 release
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 14:42:01 +0900] rev 42636
rust-filepatterns: unescape comment character property
There were multiple issues in the original implementation:
a. the local variable "line" dropped soon after replace_slice() applied
b. replace_slice() was noop since br"\#".len() != b"#"
This patch uses bytes::Regex::replace_all() since it seems the simplest way
to replace bytes of arbitrary length, and I don't think we have to avoid
using Regexp here.
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:00:54 +0900] rev 42635
rust-filepatterns: use literal b'#' instead of cast
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 12:46:57 +0900] rev 42634
rust-filepatterns: fix type of warnings tuple to (bytes, bytes)
Otherwise warn() in match.py would fail if the warning contains non-ASCII
character.
We might want to add a thin ByteString wrapper around Vec<u8> to
implement ToPyObject<ObjectType = PyBytes>, but I'm not sure.
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:48:29 +0900] rev 42633
hgignore: add escape syntax test for glob patterns
The last example, [\#], is what the rust implementation fails to parse.
The other escapes can be removed by regexp engine or _globre().
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:37:24 +0900] rev 42632
hgignore: add a few more weird patterns to test case
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:30:47 +0900] rev 42631
hgignore: update \-escape test to reflect actual behavior
"\\<char>" is not an escape character but "\\" + <char>.
Martin von Zweigbergk <martinvonz@google.com> [Sat, 20 Jul 2019 11:04:49 -0700] rev 42630
py3: add a b'' prefix in tests/test-convert-identity.t
Differential Revision: https://phab.mercurial-scm.org/D6662
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Jul 2019 09:43:50 -0700] rev 42629
lookup: don't use "00changelog.i@None" when lookup of prefix fails
We were shadowing the "node" variable, so we always passed None to the
LookupError instead of the node we meant to pass.
(This showed up in py3 tests since py3 doesn't like to format None
using "%s".)
Differential Revision: https://phab.mercurial-scm.org/D6661
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:23:21 -0400] rev 42628
py3: fix test-setdiscovery.t on Python 3 by conditionalizing two lines
I'm not clear why this behaves very slightly differently on Python 3,
but I'm also not concerned about it.
Differential Revision: https://phab.mercurial-scm.org/D6658
Taapas Agrawal <taapas2897@gmail.com> [Fri, 19 Jul 2019 01:49:10 +0530] rev 42627
commands: removed part of description from abort and continue
The description for registration of new `continuefunc` or `abortfunc`
is removed as it is not required from user perspective.
Differential Revision: https://phab.mercurial-scm.org/D6660
Matt Harbison <matt_harbison@yahoo.com> [Sat, 20 Jul 2019 22:18:22 -0400] rev 42626
tests: glob over some timing numbers in test-shelve.t
The Windows bot is slow enough that it was 2s in the first hunk.
Differential Revision: https://phab.mercurial-scm.org/D6663
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:18:20 -0400] rev 42625
py3: another passing test
Differential Revision: https://phab.mercurial-scm.org/D6656
Augie Fackler <augie@google.com> [Thu, 18 Jul 2019 14:19:41 -0400] rev 42624
cleanup: remove redundant import
For some reason the import checker only caught this on py3.
Differential Revision: https://phab.mercurial-scm.org/D6657
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 18 Jul 2019 21:10:17 +0530] rev 42623
shelve: modify help text on --interactive
We now have `unshelve --interactive` after rHG5162753c4c14.
So, the help text on `shelve --interactive` suggesting that it
only works for `shelve` can be removed.
Differential Revision: https://phab.mercurial-scm.org/D6654
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 18 Jul 2019 20:54:26 +0530] rev 42622
unshelve: mark unshelve interactive as experimental
This is a follow-up patch to rHG5162753c4c14.
We have the logic for interactive unshelve under `_rebaserestorecommit()`.
So, we might get conflicts even if there are conflicting changes other than
selected changes by the user. We should mark unshelve `--interactive` as
`EXPERIMENTAL` until we solve this issue.
Differential Revision: https://phab.mercurial-scm.org/D6653
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 02 Jul 2019 12:59:58 -0400] rev 42621
commit: improve the files field of changelog for merges
Currently, the files list of merge commits repeats all the deletions
(either actual deletions, or files that got renamed) that happened
between base and p2 of the merge. If p2 is the main branch, the list
can easily be much bigger than the change being merged.
This results in various problems worth improving:
- changelog is bigger than necessary
- `hg log directory` lists many unrelated merge commits, and `hg log
-v -r commit` frequently fills multiple screens worth of files
- it possibly slows down adjustlinkrev, by forcing it to read more
manifests, and that function can certainly be a bottleneck
- the server side of pulls can waste a lot of time simply opening the
filelogs for pointless files (the constant factors for opening even
a tiny filelog is apparently pretty bad)
So stop listing such files as described in the code. Impacted merge
commits and their descendants get a different hash than they would
have without this. This doesn't seem problematic, except for
convert. The previous commit helped with that in the hg->hg case (but
if you do svn->hg twice from scratch, hashes can still change).
The rest of the description is numbers. I don't have much to report,
because recreating the files list of existing repositories is not
easy:
- debugupgradeformat and bundle/unbundle don't recreate the list
- export/import tends to choke quickly applying patches or on
description that contain diffs,
- merge commits from the convert extension don't have the right files
list for reasons orthogonal to the current commit
- replaying the merge with hg update/hg merge/hg revert --all/hg
commit can end up failing in hg revert
- I wasn't sure that using debugsetparents + debugrebuilddirstate
would really build the right thing
I measured commit time before and after this change, in a case with no
files filtered out, several files filtered out (no difference) and 5k
files filtered out (+1% time).
Recreating the 100 more recent merges in a private repo, the
concatenated uncompressed files lists goes from 1.12MB to
0.52MB. Excluding 3 merges that are not representative, then the size
goes from 570k to 15k.
I converted part of mozilla-central, and observed file list shrinking
quite a bit too, starting at the very first merge, 733641d9feaf, going
from 550 files to 10 files (although they have relatively few merges,
so they probably wouldn't care).
Differential Revision: https://phab.mercurial-scm.org/D6613
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sat, 13 Jul 2019 23:45:32 -0400] rev 42620
convert: add a config option to help doing identity hg->hg conversion
I want to change the computation of the list of files modified by a
commit. In principle, this would simply change a cache. But since this
information is stored in commits rather than a cache, changing it
means changing commit hashes (going forward).
Some users rely on the convert extension from hg to hg not changing
hashes when nothing changes (usually). Allow these users to preserve
hashes despite changes to the changelog files computation by reusing
these files lists when the manifest is unchanged (since these files
list are derived from the manifest).
Differential Revision: https://phab.mercurial-scm.org/D6643
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Tue, 02 Jul 2019 12:55:51 -0400] rev 42619
tests: show the files fields of changelogs for many merges
I don't think there's coverage for many of the subtle cases, and I
found it hard to understand what the code is doing by reading it. The
test takes 40s to run on a laptop, or 9s with --chg.
I have yet to find a description of what the files field is supposed
to be for merges. I thought it could be one of:
1. the files added/modified/removed relative to p1 (wouldn't seem
useful, but `hg diff -c -r mergerev` has this behavior)
2. the files with filelog nodes not in either parent (i.e., what is
needed to create a bundle out of a commit)
3. the files added/removed/modified files by merge itself [1]
It's clearly not 1, because file contents merges are symmetric. It's
clearly not 2 because removed files and exec bit changes are
listed. It's also not 3 but I think it's intended to be 3 and the
differences are bugs.
Assuming 3, the test shows that, for merges, the list of files both
overapproximates and underapproximates. All the cases involve file
changes not in the filelog but in the manifest (existence of file
at revision, exec bit and file vs symlink).
I didn't look at all underapproximations, but they looked minor. The
two overapproximations are problematic though because they both cause
potentially long lists of files when merging cleanly.
[1] even what it means for the merge commit itself to change a file is
not completely trivial. A file in the merge being the same as in one
of the parent is too lax as it would consider that merges change
nothing when they revert all the changes done on one side. The
criteria used in the test and in the next commit for "merge didn't
touch a file" is:
- the parents and the merge all have the same file
- or, one parent didn't touch the file and the other parent contains
the same file as the merge
Differential Revision: https://phab.mercurial-scm.org/D6612
Ian Moody <moz-ian@perix.co.uk> [Tue, 16 Jul 2019 19:18:16 +0100] rev 42618
phabricator: handle local:commits time being string or int
When setting local:commits arcanist has different behaviour depending on
whether the repo is git or hg. With hg it sets the time as a number, since it
calls PHP's strtotime on the value, but with git it sets it as a string.
Normally this wouldn't be an issue since phabread wouldn't be interacting with
Phabricator Revisions for git repos, but Mozilla has a secondary workflow for
git users that uses the git-cinnabar tool to interact with their hg repos. When
a git-cinnabar user uses the moz-phab tool to submit patches for mozilla-central
it makes use of Mozilla's fork of arcanist, which works with their local git
version of m-c, and thus sets the local:commit time as a string, and then
translates the commit hashes.
Currently when encountering such DREVS phabread dies with "TypeError: %d format:
a number is required, not str".
phabsend also used to set it as a string but wouldn't have encountered the
issue with its own DREVs since it would read hg:meta first.
Differential Revision: https://phab.mercurial-scm.org/D6650
Ian Moody <moz-ian@perix.co.uk> [Tue, 16 Jul 2019 18:38:38 +0100] rev 42617
phabricator: demonstrate broken phabread on string local:commit times
Differential Revision: https://phab.mercurial-scm.org/D6649
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 02 Jul 2019 18:02:12 +0530] rev 42616
unshelve: add interactive mode
Until now, there is no way to `unshelve` selected changes only from
the stored shelve as given in issue6162. This patch makes `unshelve`
perform with certain changes only by adding an interactive mode.
Differential Revision: https://phab.mercurial-scm.org/D6596
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 07 Jul 2019 10:54:41 -0400] rev 42615
blackbox: disable extremely verbose logging (issue6110)
This is maybe not the best way to go about fixing this, but anything
is better than the status quo.
Differential Revision: https://phab.mercurial-scm.org/D6611
Taapas Agrawal <taapas2897@gmail.com> [Wed, 17 Jul 2019 22:24:17 +0530] rev 42614
continue: added support for unshelve
This patch adds the support for `ushelve` in `hg continue` plan.
`hgcontinueunshelve()` has been created for independent calls.
In case an interrupted unshelve is resumed via hg continue the
shelvedstate needs to be loaded seperately. This has been
ensured by `_loadunshelvedstate()`
`hgcontinueunshelve()` is then registered as `continuefunc` for state
detection API.
Results are shown as tests.
Differential Revision: https://phab.mercurial-scm.org/D6652
Taapas Agrawal <taapas2897@gmail.com> [Tue, 16 Jul 2019 01:59:28 +0530] rev 42613
continue: added support for rebase
This adds support of rebase to hg continue plan.
An independent continue logic for rebase is created
under continuerebase() function. For this a seperate
rebaseruntime object is created under the function to
handle an interrupted rebasestate.
Results of tests are shown.
Differential Revision: https://phab.mercurial-scm.org/D6646
Taapas Agrawal <taapas2897@gmail.com> [Mon, 15 Jul 2019 22:23:31 +0530] rev 42612
continue: added logic for hg continue
This is part of GSoC19 project `Implement abort and
continue commands`. This patch is part of the continue plan.
This adds the basic logic for hg continue. This command
aborts an multistep operation like graft, histedit, rebase,
transplant and unshelve if they are in an unfinished state.
The first part of the logic is determining the unfinished
operation from the state detection API under statemod.
This API is extended to support hg continue by adding a method
to register the abort logic as a function (here continuefunc).
Once the unfinished operation is determined the registered
logic is used to resume the command in case it is interrupted.
The benefit of this kind of framework is that any new extension
developed can support hg continue by registering the command
and logic under statedetection API.
hg continue currently supports --dry-run/-n flag only.
It is used to dry run hg abort
Differential Revision: https://phab.mercurial-scm.org/D6645
Raphaël Gomès <rgomes@octobus.net> [Wed, 17 Jul 2019 18:15:51 +0200] rev 42611
rust-utils: remove buggy assertion
While this assertion had good intentions, it broke existing behavior with a
nasty panic.
Differential Revision: https://phab.mercurial-scm.org/D6651
Raphaël Gomès <rgomes@octobus.net> [Wed, 10 Jul 2019 17:41:07 +0200] rev 42610
rust-utils: add docstrings and doctests for utils.rs
Differential Revision: https://phab.mercurial-scm.org/D6635
Raphaël Gomès <rgomes@octobus.net> [Tue, 02 Jul 2019 17:15:03 +0200] rev 42609
rust: switch hg-core and hg-cpython to rust 2018 edition
Many interesting changes have happened in Rust since the Oxidation Plan was
introduced, like the 2018 edition and procedural macros:
- Opting in to the 2018 edition is a clear benefit in terms of future
proofing, new (nice to have) syntactical sugar notwithstanding. It
also has a new non-lexical, non-AST based borrow checker that has
fewer bugs(!) and allows us to write correct code that in some cases
would have been rejected by the old one.
- Procedural macros allow us to use the PyO3 crate which maintainers have
expressed the clear goal of compiling on stable, which would help in
code maintainability compared to rust-cpython.
In this patch are the following changes:
- Removing most `extern crate` uses
- Updating `use` clauses (`crate` keyword, nested `use`)
- Removing `mod.rs` in favor of an aptly named module file
Like discussed in the mailing list (
https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-July/132316.html
), until Rust integration in Mercurial is considered to be out of the
experimental phase, the maximum version of Rust allowed is whatever the latest
version Debian packages.
Differential Revision: https://phab.mercurial-scm.org/D6597