Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 Jun 2020 00:51:36 +0530] rev 44799
Added signature for changeset 065704cbdbdb
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 06 Jun 2020 00:51:28 +0530] rev 44798
Added tag 5.4.1 for changeset 065704cbdbdb
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 06:40:15 +0200] rev 44797
py3: update comment to account for Python 2 and Python 3 differences
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 07:20:52 +0200] rev 44796
py3: add warning about buffering behavior of pycompat.{stdout,stderr}
Manuel Jacob <me@manueljacob.de> [Fri, 05 Jun 2020 04:10:37 +0200] rev 44795
tests: fix indentation
Yuya Nishihara <yuya@tcha.org> [Tue, 02 Jun 2020 20:40:06 +0900] rev 44794
graft: fix --base value to be saved in state file
'True' just works because it is treated as an integer revision '1' and
only the truthiness of the basectx is important. If multiple source revisions
were supported with --base, the resumed graft operation would go wrong.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:53 +0200] rev 44793
flags: also test merge with executable bit removed
This might catch more bug in the future.
Differential Revision: https://phab.mercurial-scm.org/D8536
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:42 +0200] rev 44792
flags: also test the removal of the exec flag
Differential Revision: https://phab.mercurial-scm.org/D8535
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:31 +0200] rev 44791
flags: read flag from dirstate/disk for workingcopyctx (issue5743)
In 491855ea9d62, various piece of code are moved from committablectx to
workingctx. The reason given is "These read from the dirstate, so they shouldn't
be used in other subclasses."
At least for `flags` this change introduce a bug, because the value flags end up being
read from `_manifest` disregarding the actual state in the working copy (ie: on
disk). When merging exec flag change with renames, this means a new files (the
local content, renamed) is properly written on disk, with the right flags, but
the flags part is later ignored when actually reading flags during merge.
It is not clear to me why the `flags` function was moved, because the code does
not actually hit the dirstate (the reason given in the changeset description).
So I am moving it back to were it comes from and we use a simpler version of
that code (that hit the dirstate everytime) in workingcopyctx. This fix the last
know bug with merging rename and executable byte changes.
Other similar bug might be lurking in 491855ea9d62, but I have not investigated
them.
Differential Revision: https://phab.mercurial-scm.org/D8534
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:19 +0200] rev 44790
flags: actually merge flags in simplemerge
Since b86fc43e4b73, the local flag were blindly taken. This resulted in bug when
rename are involved. exec flag change are now properly merged (when merged from
the rename side).
Another bug is affecting this when merging from the side without the rename.
Differential Revision: https://phab.mercurial-scm.org/D8533
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:38:07 +0200] rev 44789
flags: add a test for merging exec flag change with rename and file change
Changing the file activate other code path that also have bugs… There are two
distinct bugs depending of which side of the merge you stand on. They both
leading to exec flag loss.
We add tests for both, the fix are coming in later changesets.
Differential Revision: https://phab.mercurial-scm.org/D8532
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:56 +0200] rev 44788
flags: account for flag change when tracking rename relevant to merge
There are some logic filtering rename to the one relevant to the merge. That
logic was oblivious of flag change, leading to exec flag being dropped when
merged with a renamed.
There are two others bugs affecting this scenario. This patch fix the was where
there is not modification involved except for the flag change. Fixes for the
other bug are coming in later changesets.
Differential Revision: https://phab.mercurial-scm.org/D8531
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:44 +0200] rev 44787
flags: also test merging a rename with and exec flag change
This case is currently buggy and was not tested. This is probably a quite old
regression. The next changeset fix this case. Move exec+rename related bug will
gain a test later.
To highlight the expected behavior the currently missing line are marked with (false !)
and the bad one with (true !)
note: we should probably gain explicit "test bool" for this usecases.
Differential Revision: https://phab.mercurial-scm.org/D8530
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 May 2020 20:37:33 +0200] rev 44786
flags: introduce explicit testing for merging change to exec flag
It turns out that we do not seems to test the simple case for merging exec flag
changes. More advanced case are test (merging exec flag without a common
ancestors, merging with a symlink, etc…) but not the basic.
We are about introduce various fixes to merging flag change across renames,
having the most basic case tested first seems useful.
note: We are only testing "adding" an exec flag here, not removing it. We
introduce basic test on stable and will consolidate them on default.
Differential Revision: https://phab.mercurial-scm.org/D8529
Charles Chamberlain <cchamberlain@janestreet.com> [Tue, 26 May 2020 11:14:07 -0400] rev 44785
graft-state: save --base in graft's state, fixing bug with graft --continue
Without this change, running graft --continue after grafting a merge commit using --base
(and encountering conflicts) will output "skipping ungraftable merge revision" even though
we specified a base in the initial graft command.
Graft's improve behaviour is reflected in test-graft.t.
Differential Revision: https://phab.mercurial-scm.org/D8578
Manuel Jacob <me@manueljacob.de> [Fri, 15 May 2020 00:53:37 +0200] rev 44784
setup: raise minimum Python version to 2.7.4
On older Python versions, Mercurial is not really usable because of
https://bugs.python.org/issue10211.
Recently someone reported a crash on the mailing list when running Mercurial
on Python 2.7.3. There was consensus that fixing compatibility for a Python
version more than 7 years old is not worth it. So, instead of making Mercurial
crash with an obscure exception, this patch raises the minimum Python version
to 2.7.4.
Connor Sheehan <sheehan@mozilla.com> [Tue, 19 May 2020 16:18:41 -0400] rev 44783
fsmonitor: coerce `clock` variable to byte-string (issue6321)
Callers of `fsmonitor.state.setlastclock` pass their arguments
wrapped in `pycompat.sysbytes` to ensure the value is a `bytes`
on Python 3. However in `fsmonitor.poststatus.__call__`, if the
return value of `getlastclock()` is `None`, we use the value of
`fsmonitor.poststatus._startclock` instead, which is not converted
to a byte string in the same manner. This commit converts the
value of `startclock` to a byte string using `pycompat.sysbytes`
in the constructor for `poststatus`, to avoid the "`str` + `bytes`"
error from issue 6321.
Differential Revision: https://phab.mercurial-scm.org/D8573
Charles Chamberlain <cchamberlain@janestreet.com> [Thu, 14 May 2020 23:14:24 -0400] rev 44782
py3: change default priority and length used for sorting hooks to be compatible with python 3
The call to `sorted(hooks.values())` can on line 213 of hooks.py can raise when using
python 3. For instance, when hooks.values is `[(0, 2, b'post-commit.check-status', b''),
(None, None, b'changegroup.app-hooks', <object object at 0x7f5279885590>)]`, the error is
`TypeError: '<' not supported between instances of 'NoneType' and 'int'`
This fix keeps the same order that was used in python 2 without relying on comparison with
None.
Differential Revision: https://phab.mercurial-scm.org/D8527
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 May 2020 08:31:32 -0700] rev 44781
relnotes: copy "next" to "5.4" and clear "next"
This is the same thing as we've done for the previous few releases.
Differential Revision: https://phab.mercurial-scm.org/D8546
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 May 2020 13:08:02 +0200] rev 44780
dirstate: make sure the dirstate is loaded before the changelog (issue6303)
Before this change, it was possible for the changelog to be loaded before the
dirstate. If a transaction happens betwen the changelog and dirstate reading,
the dirstate can up end poitning toward a revision not existing in the (olded)
changelog. This lead to a warning.
With this revision, we preload the dirstate parent before reading the changelog.
This has a negligible performance impact on performance for all case we are
tracking.
Differential Revision: https://phab.mercurial-scm.org/D8528
Raphaël Gomès <rgomes@octobus.net> [Mon, 11 May 2020 16:44:11 +0200] rev 44779
rust-dirstatemap: don't read the dirstate when requesting parents
A future patch for issue 6303 reveals a big performance regression in the Rust
`DirstateMap` that reads the entire dirstate when requesting parents instead
of the first 40 bytes.
`perfdiscovery` gets a *significant* speedup (from 0.101 to 0.016) when applied
against said patch.
I'm assuming it has other performance benefits, but this is already a good
enough win.
Differential Revision: https://phab.mercurial-scm.org/D8513
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Thu, 14 May 2020 10:24:52 -0400] rev 44778
py3: fix exception in pull when several things happen to a bookmark
Specifically, when `changes` is:
[(b'@upstream-committed', None, <function ui.status>, b'updating bookmark @upstream-committed\n'),
(b'@upstream-committed', binary-node, <function ui.warn>, b'divergent bookmark @ stored as @upstream-committed\n')]
sorting the list raises:
TypeError: '<' not supported between instances of 'bytes' and 'NoneType'
Differential Revision: https://phab.mercurial-scm.org/D8523
Joerg Sonnenberger <joerg@bec.de> [Tue, 12 May 2020 22:20:56 +0200] rev 44777
fastexport: adjust output to be more canonical
For time zones, git doesn't consider +0 and -0 the same timezone, so use
the former canonically. Add a test case to ensure that non-UTC offsets
are handled correctly. The real name part of the committer name is
normally not quoted, so don't enforce that.
Differential Revision: https://phab.mercurial-scm.org/D8522
Peter Arrenbrecht <peter@arrenbrecht.ch> [Mon, 11 May 2020 08:13:40 +0200] rev 44776
bash_completion: do not use aliased hg if it sources a script (issue6308)
I have an alias that sources a script around hg. Mercurial's bash_completion
script tries to use this as its main hg binary. But sourcing a wrapper breaks
Bash's completion. So this patch disables using the alias as the hg binary if
it starts with "source ".
Alias resolution was introduced in rev 191ab08e7099 for users with
"alias hg='hg --some_opts'".
See https://www.mercurial-scm.org/repo/hg/rev/191ab08e7099
Manuel Jacob <me@manueljacob.de> [Tue, 12 May 2020 01:03:12 +0200] rev 44775
demandimport: fix compatibility with meta path finders w/o find_spec() method
Meta path finders got a find_spec() method in Python version 3.4. The
sys.meta_path documentation says that the deprecated find_module() method is
used as a fallback.
Setuptool’s VendorImporter still doesn’t have the find_spec() method,
which resulted in a crash e.g. within a virtual environment. For reference, I
opened an issue for that: https://github.com/pypa/setuptools/issues/2104.
An alternative implementation would have been to implement a wrapper for
find_module() itself and raise an AttributeError when accessing find_spec() if
the wrapped finder doesn’t have it.
Joerg Sonnenberger <joerg@bec.de> [Thu, 07 May 2020 23:40:05 +0200] rev 44774
tests: fix timer scaling in wait-on-file
When using the default test timeouts, wait-on-file would not wait for $n
seconds, but $n/100 seconds. This resulted in easy timeouts on even
moderately busy fast machines. Fix the scaling to apply in all cases.
Adjust the stepping slightly to be nicer to systems with the historic
100Hz time base to ensure that the scheduler actually switches to a
different process and gives them time to work.
Differential Revision: https://phab.mercurial-scm.org/D8505
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 09 May 2020 20:25:07 +0200] rev 44773
manifest-cache: ignore IOError while writing
If the wcache directory is non writable for some reason (eg: belong to root).
Trying to write to it currently crash Mercurial. Instead we ignore the error and
skip writing that cache.
We should probably improve the user experience of multiple users interacting
with the same repository. However this is not an adventure for stable.
Differential Revision: https://phab.mercurial-scm.org/D8512
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:40:17 -0700] rev 44772
copy: give better error message when no source paths found with --at-rev
The new error message matches what we show when marking copies in the
working copy.
Differential Revision: https://phab.mercurial-scm.org/D8496
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:41:37 -0700] rev 44771
tests: show poor error message for `hg cp -A --at-rev . non-existent dst`
Differential Revision: https://phab.mercurial-scm.org/D8495
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 10:33:56 -0700] rev 44770
copy: to find copy source, walk parent of revision we're marking copies in
As shown in the previous patch, `hg cp --after --at-rev . src dst`
fails if `src` is not in `.`. It seems obvious that you should always
walk the *parent* of the revision you're marking copies in, but that's
not how it was done for the working copy, and I didn't think to change
it when marking copies in a non-working-copy commit.
This patch fixes that by walking the parent commit instead, but only
if we're marking copies for a non-working-copy commit. We need to
leave the working-copy code unchanged because it depends on the weird
behavior of `workingctx.walk()`. With these changes, there's very
little overlap between the working-copy version and the
non-working-copy version of `walkpats()`, but I've refrained from
cleaning that up on the stable branch.
Differential Revision: https://phab.mercurial-scm.org/D8494
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:41:01 -0700] rev 44769
tests: show that `hg cp -A --at-rev .` doesn't work for renames
I clearly forgot to implement (and test) support for marking of
renames when I added support for marking of copies :(
Differential Revision: https://phab.mercurial-scm.org/D8493
Raphaël Gomès <rgomes@octobus.net> [Fri, 08 May 2020 01:19:48 +0200] rev 44768
formatting: add missing newline
Differential Revision: https://phab.mercurial-scm.org/D8509