Julien Cristau <jcristau@mozilla.com> [Fri, 07 Feb 2020 15:55:21 +0100] rev 44325
hghave: cache the result of gethgversion
hghave --test-features calls it 90 times, each one calling hg --version
which takes a tenth of a second on my workstation, adding up to about
10s win on test-hghave.t.
Fixes https://bugs.debian.org/939756
Differential Revision: https://phab.mercurial-scm.org/D8092
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 14:11:43 -0800] rev 44324
clean: delete obsolete unlinking of .hg/graftstate
The responsibility for clearing it is now in
`cmdutil.clearunfinished()`, so we shouldn't have to unlink it in
`hg.clean()`.
Differential Revision: https://phab.mercurial-scm.org/D7992
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Feb 2020 10:16:30 -0800] rev 44323
copies: avoid filtering by short-circuit dirstate-only copies earlier
The call to `y.ancestor(x)` triggered repo filtering, which we'd like
to avoid in the simple `hg status --copies` case.
Differential Revision: https://phab.mercurial-scm.org/D8071
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Feb 2020 10:14:44 -0800] rev 44322
tests: add test showing that repo filter is calculated for `hg st --copies`
Differential Revision: https://phab.mercurial-scm.org/D8070
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 11:40:15 -0500] rev 44321
lfs: enable workers by default
With the stall issue seemingly fixed, there's no reason not to use workers. The
setting is left for now to keep the test output deterministic, and in case other
issues come up. If none do, this can be converted to a developer setting for
usage with the tests.
Differential Revision: https://phab.mercurial-scm.org/D7963
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 11:32:33 -0500] rev 44320
lfs: fix the stall and corruption issue when concurrently uploading blobs
We've avoided the issue up to this point by gating worker usage with an
experimental config. See 10e62d5efa73, and the thread linked there for some of
the initial diagnosis, but essentially some data was being read from the blob
before an error occurred and `keepalive` retried, but didn't rewind the file
pointer. So the leading data was lost from the blob on the server, and the
connection stalled, trying to send more data than available.
In trying to recreate this, I was unable to do so uploading from Windows to
CentOS 7. But it reproduced every time going from CentOS 7 to another CentOS 7
over https.
I found recent fixes in the FaceBook repo to address this[1][2]. The commit
message for the first is:
The KeepAlive HTTP implementation is bugged in it's retry logic, it supports
reading from a file pointer, but doesn't support rewinding of the seek cursor
when it performs a retry. So it can happen that an upload fails for whatever
reason and will then 'hang' on the retry event.
The sequence of events that get triggered are:
- Upload file A, goes OK. Keep-Alive caches connection.
- Upload file B, fails due to (for example) failing Keep-Alive, but LFS file
pointer has been consumed for the upload and fd has been closed.
- Retry for file B starts, sets the Content-Length properly to the expected
file size, but since file pointer has been consumed no data will be uploaded,
causing the server to wait for the uploaded data until either client or
server reaches a timeout, making it seem as our mercurial process hangs.
This is just a stop-gap measure to prevent this behavior from blocking Mercurial
(LFS has retry logic). A proper solutions need to be build on top of this
stop-gap measure: for upload from file pointers, we should support fseek() on
the interface. Since we expect to consume the whole file always anyways, this
should be safe. This way we can seek back to the beginning on a retry.
I ported those two patches, and it works. But I see that `url._sendfile()` does
a rewind on `httpsendfile` objects[3], so maybe it's better to keep this all in
one place and avoid a second seek. We may still want the first FaceBook patch
as extra protection for this problem in general. The other two uses of
`httpsendfile` are in the wire protocol to upload bundles, and to upload
largefiles. Neither of these appear to use a worker, and I'm not sure why
workers seem to trigger this, or if this could have happened without a worker.
Since `httpsendfile` already has a `close()` method, that is dropped. That
class also explicitly says there's no `__len__` attribute, so that is removed
too. The override for `read()` is necessary to avoid the progressbar usage per
file.
[1] https://github.com/facebookexperimental/eden/commit/c350d6536d90c044c837abdd3675185644481469
[2] https://github.com/facebookexperimental/eden/commit/77f0d3fd0415e81b63e317e457af9c55c46103ee
[3] https://www.mercurial-scm.org/repo/hg/file/5.2.2/mercurial/url.py#l176
Differential Revision: https://phab.mercurial-scm.org/D7962
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:34:15 -0500] rev 44319
lfs: add a method to the local blobstore to convert OIDs to file paths
This is less ugly than passing an open callback to the `httpsendfile`
constuctor.
Differential Revision: https://phab.mercurial-scm.org/D7961
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 14:47:38 -0800] rev 44318
merge: introduce a revert_to() for that use-case
In the same vein as the previous patch.
Differential Revision: https://phab.mercurial-scm.org/D7901
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:30:25 -0800] rev 44317
merge: introduce a clean_update() for that use-case
I find it hard to understand what value to pass for all the arguments
to `merge.update()`. I would like to introduce functions that are more
specific to each use-case. We already have `graft()`. This patch
introduces a `clean_update()` and uses it in some places to show that
it works.
Differential Revision: https://phab.mercurial-scm.org/D7902
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 16:16:15 -0500] rev 44316
manifest: fix _very_ subtle bug with exact matchers passed to walk()
Prior to this fix, manifestdict.walk() with an exact matcher would blindly
list the files in the matcher, even if they weren't in the manifest. This was
exposed by my next patch where I rewrite filesnotin() to use walk() instead of
matches().
Differential Revision: https://phab.mercurial-scm.org/D8081
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:08:45 +0100] rev 44315
rust-utils: add `Escaped` trait
This will be used as a general interface for displaying things to the user.
The upcoming `IncludeMatcher` will use it to store its patterns in a
user-displayable string.
Differential Revision: https://phab.mercurial-scm.org/D7870
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:04:32 +0100] rev 44314
rust-dirs-multiset: add `DirsChildrenMultiset`
In a future patch, this structure will be needed to store information needed by
the (also upcoming) `IgnoreMatcher`.
Differential Revision: https://phab.mercurial-scm.org/D7869
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 16:50:35 +0100] rev 44313
rust-hg-path: add useful methods to `HgPath`
This changeset introduces the use of the `pretty_assertions` crate for easier
to read test output.
Differential Revision: https://phab.mercurial-scm.org/D7867
Raphaël Gomès <rgomes@octobus.net> [Wed, 05 Feb 2020 17:05:37 +0100] rev 44312
rust-pathauditor: add Rust implementation of the `pathauditor`
It does not offer the same flexibility as the Python implementation, but
should check incoming paths just as well.
Differential Revision: https://phab.mercurial-scm.org/D7866
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 22 Jan 2020 03:17:06 +0530] rev 44311
py3: catch AttributeError too with ImportError
Looks like py3 raises AttributeError instead of ImportError. This is caught on
windows.
Differential Revision: https://phab.mercurial-scm.org/D7965
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 15:15:18 -0500] rev 44310
context: use manifest.walk() instead of manifest.match() to get file list
The former doesn't create a whole extra manifest in order to produce the
matching file list, which is all we actually cared about here. Sigh.
Differential Revision: https://phab.mercurial-scm.org/D8080
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 15:01:22 -0500] rev 44309
manifest: remove `.new()` from the interface
Nothing used it.
Differential Revision: https://phab.mercurial-scm.org/D8079
Kyle Lippincott <spectral@google.com> [Wed, 29 Jan 2020 13:39:50 -0800] rev 44308
chg: force-set LC_CTYPE on server start to actual value from the environment
Python 3.7+ will "coerce" the LC_CTYPE variable in many instances, and this can
cause issues with chg being able to start up. D7550 attempted to fix this, but a
combination of a misreading of the way that python3.7 does the coercion and an
untested state (LC_CTYPE being set to an invalid value) meant that this was
still not quite working.
This change will cause differences between chg and hg: hg will have the LC_CTYPE
environment variable coerced, while chg will not. This is unlikely to cause any
detectable behavior differences in what Mercurial itself outputs, but it does
have two known effects:
- When using hg, the coerced LC_CTYPE will be passed to subprocesses, even
non-python ones. Using chg will remove the coercion, and this will not
happen. This is arguably more correct behavior on chg's part.
- On macOS, if you set your region to Brazil but your language to English,
this isn't representable in locale strings, so macOS sets LC_CTYPE=UTF-8. If
this value is passed along when ssh'ing to a non-macOS machine, some
functions (such as locale.setlocale()) may raise an exception due to an
unsupported locale setting. This is most easily encountered when doing an
interactive commit/split/etc. when using ui.interface=curses.
Differential Revision: https://phab.mercurial-scm.org/D8039
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 03 Feb 2020 09:00:05 +0100] rev 44307
perf: fix list formatting in perfindex documentation
Differential Revision: https://phab.mercurial-scm.org/D8067
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Feb 2020 09:14:36 +0100] rev 44306
test: simplify test-amend.t to avoid race condition
Insted on relying on sleep, we could simply have the editor do the file change.
This remove the reliance on "sleep" and avoid test failing on heavy load
machine.
To test this, I reverted the code change in 5558e3437872 and the test started
failing again.
Differential Revision: https://phab.mercurial-scm.org/D8065
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Dec 2019 11:32:36 +0100] rev 44305
test: document test-copy-move-merge.t
Differential Revision: https://phab.mercurial-scm.org/D8077
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 22:16:36 -0500] rev 44304
manifest: remove optional default= argument on flags(path)
It had only one caller inside manifest.py, and treemanifest was
actually incorrectly implemented. treemanifest is still missing the
fastdelta() method from the interface (and so doesn't yet conform),
but this is at least progress.
Differential Revision: https://phab.mercurial-scm.org/D8069
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 11:56:02 -0500] rev 44303
resourceutil: blacken
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 11:51:52 -0500] rev 44302
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 10:53:50 -0800] rev 44301
rebase: abort if the user tries to rebase the working copy
I think it's more correct to treat `hg rebase -r 'wdir()' -d foo`
as `hg co -m foo`, but I'm instead making it error out. That's partly
because it's probably what the user wanted (in the case I heard from a
user, they had done `hg rebase -s f` where `f` resolved to `wdir()`)
and partly because I don't want to think about more complicated cases
where the user specifies the working copy together with other commits.
Differential Revision: https://phab.mercurial-scm.org/D8057
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 10:41:50 -0800] rev 44300
tests: add tests for rebasing wdir() revision
Differential Revision: https://phab.mercurial-scm.org/D8056
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 13:29:26 -0800] rev 44299
merge: when rename was made on both sides, use ancestor as merge base
When both sides of a merge have renamed a file to the same place, we
would treat that as a "both created" action in merge.py. That means
that we'd use an empty diffbase. It seems better to use the copy
source as diffbase. That can be done by simply dropping code that
prevented us from doing that. I think I did it that way in
57203e0210f8 (copies: calculate mergecopies() based on pathcopies(),
2019-04-11) only to preserve the existing behavior. I also suspect it
was just an accident that it behaved that way before that commit.
Note that until fa9ad1da2e77 (merge: start using the per-side copy
dicts, 2020-01-23), it was non-deterministic (depending on iteration
order of the `allsources` set in `copies._fullcopytracing()`) which
source was used in the affected test case in test-rename-merge1.t. We
could easily have fixed that by sorting them, but now we can instead
detect the case (the TODO added in the previous patch).
Differential Revision: https://phab.mercurial-scm.org/D7974
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 08:47:32 -0800] rev 44298
absorb: graduate -i flag from experimental
The interactive mode seems to work well. I have previously thought
that `-i` should be what `-e` does, but the current behavior matches
what other `-i` flags do (select a subset of the hunks), so I think
that is what we want.
Differential Revision: https://phab.mercurial-scm.org/D8055
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:30:24 +0900] rev 44297
rust-cpython: remove PySharedRefCell and its companion structs
Also updates py_shared_iterator!() documentation accordingly.
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:26:23 +0900] rev 44296
rust-cpython: switch to upstreamed version of PySharedRefCell
Our PyLeaked is identical to cpython::UnsafePyLeaked. I've renamed it because
it provides mostly unsafe functions.
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:21:06 +0900] rev 44295
rust-cpython: rename inner_shared() to inner()
The "shared" accessor will be automatically generated, and will have the
same name as the data itself.
Yuya Nishihara <yuya@tcha.org> [Fri, 31 Jan 2020 00:08:30 +0900] rev 44294
rust-cpython: use PyList.insert() instead of .insert_item()
Silences the deprecated warning.
https://github.com/dgrunwald/rust-cpython/commit/e8cbe864841714c5555db8c90e057bd11e360c7f
Yuya Nishihara <yuya@tcha.org> [Fri, 31 Jan 2020 00:01:29 +0900] rev 44293
rust-cpython: bump cpython to 0.4 to switch to upstreamed PySharedRef
Yuya Nishihara <yuya@tcha.org> [Thu, 30 Jan 2020 23:57:19 +0900] rev 44292
rust: update dependencies
For no particular reason, but just because I'll bump the rust-cpython version.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Jan 2020 12:50:27 +0100] rev 44291
contrib: a small script to nudge lingering diff
After a discussion on IRC with various reviewers. It seems like a good idea to
have some automatic cleanup of old, inactive diffs.
Here is a small script able to do so. I am preparing to unleash it on our
phabricator instance.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 26 Jan 2020 16:23:57 -0800] rev 44290
packaging: add support for PyOxidizer
I've successfully built Mercurial on the development tip of
PyOxidizer on Linux and Windows. It mostly "just works" on Linux.
Windows is a bit more finicky.
In-memory resource files are probably not all working correctly
due to bugs in PyOxidizer's naming of modules. PyOxidizer now
now supports installing files next to the produced binary. (We
do this for templates in the added file.) So a workaround
should be available.
Also, since the last time I submitted support for PyOxidizer,
PyOxidizer gained the ability to auto-generate Rust projects
to build executables. So we don't need to worry about vendoring
any Rust code to initially support PyOxidizer. However, at some
point we will likely want to write our own command line driver
that embeds a Python interpreter via PyOxidizer so we can run
Rust code outside the confines of a Python interpreter. But that
will be a follow-up.
I would also like to add packaging.py CLI commands to build
PyOxidizer distributions. This can come later, if ever.
PyOxidizer's new "targets" feature makes it really easy to define
packaging tasks in its Starlark configuration file. While not
much is implemented yet, eventually we should be able to produce
MSIs, etc using a `pyoxidizer build` one-liner. We'll get there...
Differential Revision: https://phab.mercurial-scm.org/D7450
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 11:30:16 -0800] rev 44289
mergestate: add accessors for local and other nodeid, not just contexts
The mergestate can contain invalid nodeids. In that case,
`mergestate.localctx` or `mergestate.otherctx` will fail. This patch
provides a way of accessing the nodeid without failing in such cases.
Differential Revision: https://phab.mercurial-scm.org/D8040
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 22:24:16 -0800] rev 44288
rebase: define base in only place in defineparents()
Just a little refactoring to prepare for the next patch.
Differential Revision: https://phab.mercurial-scm.org/D7906
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 16:16:57 -0800] rev 44287
tests: use full `uncommit` command name in tests
I'm about to add a `hg uncopy`, so the `hg unc` we used for `hg
uncommit` would become ambiguous.
Differential Revision: https://phab.mercurial-scm.org/D8028
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 14:53:23 -0800] rev 44286
graft: default `base` argument to common case of `ctx.p1()`
I also updated the callers that wanted that, partly to simplify and
partly to show that it works.
Differential Revision: https://phab.mercurial-scm.org/D8027
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 13:12:24 -0800] rev 44285
graft: let caller pass in overlayworkingctx to merge.graft()
Passing in a different `wctx` than `repo[None]` is useful because it
allows the caller to decide to not touch the working directory.
Differential Revision: https://phab.mercurial-scm.org/D8026
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 23:14:31 -0800] rev 44284
copies: fix crash when copy source is not in graft base
Differential Revision: https://phab.mercurial-scm.org/D8046
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 23:05:02 -0800] rev 44283
tests: add test showing crash when shelving ghosted rename target
When you `hg rename` a file and then delete the rename target, `hg
shelve` will give you a traceback.
Note that the shelve succeeds and the shelve is correct, it's just the
update to the parent that fails (i.e. to the parent of the commit that
was created for the shelve).
This can be squashed into the next commit if the reviewer prefers.
Differential Revision: https://phab.mercurial-scm.org/D8045
Yuya Nishihara <yuya@tcha.org> [Tue, 22 Oct 2019 16:04:34 +0900] rev 44282
rust-cpython: mark all PyLeaked methods as unsafe
Unfortunately, these methods can be abused to obtain the inner 'static
reference. The simplest (pseudo-code) example is:
let leaked: PyLeaked<&'static _> = shared.leak_immutable();
let static_ref: &'static _ = &*leaked.try_borrow(py)?;
// PyLeakedRef::deref() tries to bound the lifetime to itself, but
// the underlying data is a &'static reference, so the returned
// reference can be &'static.
This problem can be easily fixed by coercing the lifetime, but there are
many other ways to achieve that, and there wouldn't be a generic solution:
let leaked: PyLeaked<&'static [_]> = shared.leak_immutable();
let leaked_iter: PyLeaked<slice::Iter<'static, _>>
= unsafe { leaked.map(|v| v.iter()) };
let static_slice: &'static [_] = leaked_iter.try_borrow(py)?.as_slice();
So basically I failed to design the safe borrowing interface. Maybe we'll
instead have to add much more restricted interface on top of the unsafe
PyLeaked methods? For instance, Iterator::next() could be implemented if
its Item type is not &'a (where 'a may be cheated.)
Anyway, this seems not an easy issue, so it's probably better to leave the
current interface as unsafe, and get broader comments while upstreaming this
feature.
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 17:01:28 +0900] rev 44281
rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError
As I said, it shouldn't be an error of Python layer, but is something like
a coding error. Returning BorrowMutError makes more sense.
There's a weird hack to propagate the borrow-by-leaked state to RefCell
to obtain BorrowMutError. If we don't like it, maybe we can add our own
BorrowMutError.
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:48:34 +0900] rev 44280
rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new()
For the same reason as the previous patch. The unsafe stuff can be better
documented if these functions are inlined.
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:34:02 +0900] rev 44279
rust-cpython: inline PySharedState::try_borrow_mut()
Since the core borrowing/leaking logic has been moved to PySharedRef* and
PyLeaked*, it doesn't make sense that PySharedState had a function named
"try_borrow_mut". Let's turn it into a pure data struct.
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Oct 2019 23:34:05 +0900] rev 44278
rust-cpython: add panicking version of borrow_mut() and use it
The original borrow_mut() is renamed to try_borrow_mut().
Since leak_immutable() no longer incref the borrow count, the caller should
know if the underlying value is borrowed or not. No Python world is involved.
That's why we can simply use the panicking borrow_mut().
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:27:30 -0500] rev 44277
setup: don't skip the search for global hg.exe if there is no local instance
The point of trying not to blindly execute `hg` on Windows is that the local
hg.exe would be given precedence, and if py3 isn't on PATH, it errors out with a
modal dialog. But that's not a problem if there is no local executable that
could be run.
The problem that I recently ran into was I upgraded the repo format to use zstd.
But doing a `make clean` deletes all of the supporting libraries, causing the
next run to abort with a message about not understanding the
`revlog-compression-zstd` requirement. By getting rid of the local executable
in the previous commit when cleaning, we avoid leaving a broken executable
around, and avoid the py3 PATH problem too. There is still a small hole in that
`hg.exe` needs to be deleted before switching between py2/py3/PyOxidizer builds,
because the zstd module won't load. But that seems like good hygiene anyway.
Differential Revision: https://phab.mercurial-scm.org/D8038
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:35:08 -0500] rev 44276
make: also delete hg.exe when cleaning
This will be needed for the next patch, which has more details. It has to come
before the call into setup.py because even `python setup.py clean` calls hg to
generate the version file.
Differential Revision: https://phab.mercurial-scm.org/D8037
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 15:44:30 -0800] rev 44275
merge: start using the per-side copy dicts
The point of this patch is mostly to clarify `manifestmerge()`. I find
it much easier to reason about now.
Differential Revision: https://phab.mercurial-scm.org/D7990
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 14:35:30 -0800] rev 44274
copies: define a type to return from mergecopies()
We'll soon return two instances of many of the dicts from
`copies.mergecopies()`. That will mean that we need to return 9
different dicts, which is clearly not manageable. This patch instead
encapsulates the 4 dicts we'll duplicate in a new type. For now, we
still just return one instance of it (plus the separate `diverge`
dict).
Differential Revision: https://phab.mercurial-scm.org/D7989
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 16:45:56 -0800] rev 44273
merge: move initialization of copy dicts to one place
Differential Revision: https://phab.mercurial-scm.org/D7988
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 10:39:55 -0800] rev 44272
copies: print debug information about copies per side/branch
Differential Revision: https://phab.mercurial-scm.org/D7987
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:31:17 -0800] rev 44271
copies: make mergecopies() distinguish between copies on each side
I find it confusing that most of the dicts returned from
`mergecopies()` have entries specific to one branch of the merge, but
they're still combined into dict. For example, you can't tell if `copy
= {"bar": "foo"}` means that "foo" was copied to "bar" on the first
branch or the second.
It also feels like there are bugs lurking here because we may mistake
which side the copy happened on. However, for most of the dicts, it's
not possible that there is disagreement. For example, `renamedelete`
keeps track of renames that happened on one side of the merge where
the other side deleted the file. There can't be a disagreement there
(because we record that in the `diverge` dict instead). For regular
copies/renames, there can be a disagreement. Let's say file "foo" was
copied to "bar" on one branch and file "baz" was copied to "bar" on
the other. Beacause we only return one `copy` dict, we end up
replacing the `{"bar": "foo"}` entry by `{"bar": "baz"}`. The merge
code (`manifestmerge()`) will then decide that that means "both
renamed from 'baz'". We should probably treat it as a conflict
instead.
The next few patches will make `mergecopies()` return two instances of
most of the returned copies. That will lead to a bit more code (~40
lines), but I think it makes both `copies.mergecopies()` and
`merge.manifestmerge()` clearer.
Differential Revision: https://phab.mercurial-scm.org/D7986
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:25:40 -0800] rev 44270
pathutil: mark parent directories as audited as we go
Before 0b7ce0b16d8a (pathauditor: change parts verification order to
be root first, 2016-02-11), we used to validate child directories
before parents. It was then important to only mark the child audited
only after we had audited its parent (ancestors). I'm pretty sure we
don't need to do that any more, now that we audit parents before
children.
Differential Revision: https://phab.mercurial-scm.org/D8002
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Jan 2020 09:14:19 -0800] rev 44269
cmdutil: change check_incompatible_arguments() *arg to single iterable
This makes it clearer on the call-sites that the first argument is
special. Thanks to Yuya for the suggestion.
Differential Revision: https://phab.mercurial-scm.org/D8018
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Jan 2020 12:38:59 -0800] rev 44268
rust: remove an unnecessary set of parentheses
My build complained about this. I guess it started after I upgraded
rustc.
Differential Revision: https://phab.mercurial-scm.org/D8020
Kyle Lippincott <spectral@google.com> [Mon, 27 Jan 2020 18:16:05 -0800] rev 44267
profiling: flush stdout before writing profile to stderr
On py3, stdout and stderr appear to be buffered and this causes my command's
output to be intermixed with the profiling output.
Differential Revision: https://phab.mercurial-scm.org/D8024
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 10:40:19 -0800] rev 44266
rust: re-format with nightly rustfmt
This fixes test-check-rust-format.t.
Differential Revision: https://phab.mercurial-scm.org/D8025
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:03:00 -0500] rev 44265
tests: stablize test-rename-merge1.t on Windows
This goes with d7622fdec3b5.
Differential Revision: https://phab.mercurial-scm.org/D8036
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Sep 2019 17:27:14 +0900] rev 44264
rust-cpython: make sure PySharedRef::borrow_mut() never panics
Since it returns a Result, it shouldn't panic depending on where the
borrowing fails.
PySharedRef::borrow_mut() will be renamed to try_borrow_mut() by the next
patch.
Yuya Nishihara <yuya@tcha.org> [Tue, 22 Oct 2019 11:38:43 +0900] rev 44263
rust-cpython: remove useless wrappers from PyLeaked, just move by map()
This series prepares for migrating to the upstreamed version of PySharedRef.
I found this last batch wasn't queued while rewriting the callers.
While Option<T> was historically needed, it shouldn't be required anymore.
I wasn't aware that each filed can be just moved.
Georges Racinet <georges.racinet@octobus.net> [Mon, 27 Jan 2020 20:28:47 +0100] rev 44262
rust-node: avoid meaningless read at the end of odd prefix
This should be heavily factored out by the CPU branch predictor
anyway.
Differential Revision: https://phab.mercurial-scm.org/D8019
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 16:06:54 +0100] rev 44261
rust-nodemap: generic NodeTreeVisitor
This iterator will help avoid code duplication when we'll
implement `insert()`, in which we will need to
traverse the node tree, and to remember the visited blocks.
The structured iterator item will allow different usages from
`lookup()` and the upcoming `insert()`.
Differential Revision: https://phab.mercurial-scm.org/D7794
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 15:11:43 +0100] rev 44260
rust-nodemap: mutable NodeTree data structure
Thanks to the previously indexing abstraction,
the only difference in the lookup algorithm is that we
don't need the special case for an empty NodeTree any more.
We've considered making the mutable root an `Option<Block>`,
but that leads to unpleasant checks and `unwrap()` unless we
abstract it as typestate patterns (`NodeTree<Immutable>` and
`NodeTree<Mutated>`) which seem exaggerated in that
case.
The initial copy of the root block is a very minor
performance penalty, given that it typically occurs just once
per transaction.
Differential Revision: https://phab.mercurial-scm.org/D7793
Georges Racinet <georges.racinet@octobus.net> [Thu, 26 Dec 2019 15:47:14 +0100] rev 44259
rust-nodemap: abstracting the indexing
In the forthcoming mutable implementation, we'll have to visit
node trees that are more complex than a single slice, although
the algorithm will still be expressed in simple indexing terms.
We still refrain using `#[inline]` indications as being
premature optimizations, but we strongly hope the compiler will
indeed inline most of the glue.
Differential Revision: https://phab.mercurial-scm.org/D7792
Georges Racinet <georges.racinet@octobus.net> [Thu, 23 Jan 2020 17:18:13 +0100] rev 44258
rust-nodemap: NodeMap trait with simplest implementation
We're defining here only a small part of the immutable
methods it will have at the end. This is so we can
focus in the following changesets on the needed abstractions
for a mutable append-only serializable version.
The first implementor exposes the actual lookup
algorithm in its simplest form. It will have to be expanded
to account for the missing methods, and the special cases
related to NULL_NODE.
Differential Revision: https://phab.mercurial-scm.org/D7791
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 23:04:18 +0100] rev 44257
rust-node: handling binary Node prefix
Parallel to the inner signatures of the nodetree functions in
revlog.c, we'll have to handle prefixes of `Node` in binary
form.
Another motivation is that it allows to convert from full Node
references to `NodePrefixRef` without copy. This is expected to
be by far the most common case in practice.
There's a slight complication due to the fact that we'll be sometimes
interested in prefixes with an odd number of hexadecimal digits,
which translates in binary form by a last byte in which only the
highest weight 4 bits are considered. This is totally transparent for
callers and could be revised once we have proper means to measure
performance.
The C implementation does the same, passing the length in nybbles as
function arguments. Because Rust byte slices already have a length, we carry
the even/odd informaton as a boolean, to avoid introducing logical
redundancies and the related potential inconsistency bugs.
There are a few candidates for inlining here, but we refrain from
such premature optimizations, letting the compiler decide.
Differential Revision: https://phab.mercurial-scm.org/D7790
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:35:56 +0100] rev 44256
rust-revlog: a trait for the revlog index
As explained in the doc comment, this is the minimum needed
for our immediate concern, which is to implement a nodemap
in Rust.
The trait will be later implemented in `hg-cpython` by the
index Python object implemented in C, thanks to exposition
of the corresponding functions as a capsule.
The `None` return cases in `node()` match what the `index_node()`
C function does.
Differential Revision: https://phab.mercurial-scm.org/D7789
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:10:45 -0800] rev 44255
pathauditor: drop a redundant call to bytes.lower()
`_lowerclean(s)` calls `s.lower()`, so we don't need to do that before
calling it.
Differential Revision: https://phab.mercurial-scm.org/D8001
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:18:19 -0800] rev 44254
merge: replace a repo.lookup('.') by more typical repo['.'].node()
The `repo.lookup('.')` form comes from b3311e26f94f (merge: fix
--preview to show all nodes that will be merged (issue2043).,
2010-02-15). I don't know why that commit changed from `repo['.']`,
but I don't think there's any reason to do that. Note that performance
should not be a reason (anymore?), because repo.lookup() is
implemented by first creating a context object.
Differential Revision: https://phab.mercurial-scm.org/D7998
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:07:42 -0800] rev 44253
merge: drop now-unused "abort" argument from hg.merge()
Differential Revision: https://phab.mercurial-scm.org/D7997
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:49:21 -0800] rev 44252
merge: don't auto-pick destination with `hg merge 'wdir()'`
If the user doesn't specify a commit to merge with, we'll have
`node==None` in `commands.merge()`. We'll then try to find a good
commit to merge with. However, if the user, for some strange reason,
runs `hg merge 'wdir()'`, we'll also have `node==None` and we'll do
that same. That's clearly not the intent, so let's not do that.
It turns out we'd instead crash on that command after this patch, so I
added special handling of it too.
Differential Revision: https://phab.mercurial-scm.org/D7996
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:05:11 -0800] rev 44251
merge: call hg.abortmerge() directly and return early
It's seem really weird to go through a lot of unrelated code before we
call `hg.merge(..., abort=True)` when we can just call
`hg.abortmerge()` and return early.
Differential Revision: https://phab.mercurial-scm.org/D7995
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:00:54 -0800] rev 44250
merge: check that there are no conflicts after --abort
Same idea as in abcc82bf0717 (clean: check that there are no conflicts
after, 2020-01-24). We should reuse more code here, but that will come
later.
Differential Revision: https://phab.mercurial-scm.org/D7994
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:07:44 -0800] rev 44249
merge: use check_incompatible_arguments() for --abort
Differential Revision: https://phab.mercurial-scm.org/D7993
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 17:15:45 -0800] rev 44248
rebase: move some variables after an error cases where they're not needed
Differential Revision: https://phab.mercurial-scm.org/D7905
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 10:44:23 -0800] rev 44247
rebase: clarify a little by calculating a set in Python instead of in revset
By calculating the set in Python, we can give it a name, which helps
readability.
Differential Revision: https://phab.mercurial-scm.org/D7904
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:12:50 -0800] rev 44246
merge: avoid a negation in the definition of updatedirstate
We only use `partial` in one place: the definition of
`updatedirstate`. Let's simplify that a little.
Differential Revision: https://phab.mercurial-scm.org/D7900
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 08:32:35 -0800] rev 44245
merge: move definition of `partial` closer to where it's used
Differential Revision: https://phab.mercurial-scm.org/D7983
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 13:06:56 -0800] rev 44244
copies: extract function for finding directory renames
The directory rename code is logically quite isolated, so it makes
sense to make it physically isolated as well.
Differential Revision: https://phab.mercurial-scm.org/D7977
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:23:30 -0800] rev 44243
copies: avoid calculating debug-only stuff without --debug
`renamedeleteset` and `divergeset` is only used with
`repo.ui.debugflag`, so let's avoid calculating them otherwise. While
at it, I also added a `del renamedeleteset` for consistency.
Differential Revision: https://phab.mercurial-scm.org/D7976
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:20:12 -0800] rev 44242
copies: move early return in mergecopies() earlier
It wasn't obvious that the early return happened only when there are
no copies. That is the case, however, because if `fullcopy` is empty,
then so is `copies1` and `copies2`, and then so is `inversecopies1`
and `inversecopies2`, and then so is `allsources`, and then so is
`copy`, `diverge` and `renamedelete`.
By moving the early return earlier, we also avoid calculating the set
of added files from the base to each side.
Differential Revision: https://phab.mercurial-scm.org/D7975
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 07:00:45 -0800] rev 44241
tests: test merge of renames of different sources to same target
This is a really obscure scenario, but let's still have it tested so
we know when it changes.
Differential Revision: https://phab.mercurial-scm.org/D7985
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 09:33:02 -0800] rev 44240
clean: check that there are no conflicts after
As noted by Pulkit, there should never be any conflicts after doing a
clean update, so `hg.clean()` should never return `True`. Let's check
that assertion instead to clarify the code. The callers will now get a
`None` instead of a `False` returned, but that should be fine (both
result in a 0 exit status).
Differential Revision: https://phab.mercurial-scm.org/D7984
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 14:32:53 -0800] rev 44239
progress: delete deprecated ui.progress()
Differential Revision: https://phab.mercurial-scm.org/D7991
Raphaël Gomès <rgomes@octobus.net> [Fri, 17 Jan 2020 15:34:11 +0100] rev 44238
rust-dependencies: update rayon
This is just to make sure we use the latest version and also makes it easier
to peruse the docs.
Differential Revision: https://phab.mercurial-scm.org/D7926
Augie Fackler <augie@google.com> [Fri, 24 Jan 2020 11:05:42 -0500] rev 44237
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:08:42 -0800] rev 44236
merge: define updatedirstate a little earlier and reuse it
Differential Revision: https://phab.mercurial-scm.org/D7899
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:07:43 -0800] rev 44235
merge: don't call update hook when using in-memory context
I'm pretty sure many hook implementors will assume that they can
inspect the working copy and/or dirstate parents when the hook is
called, so I don't think we should call the hook when using an
in-memory context. The new behavior matches that of the preupdate
hook.
Differential Revision: https://phab.mercurial-scm.org/D7898
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 13:10:48 -0800] rev 44234
merge with stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 20:01:38 -0800] rev 44233
packaging: add configparser to inno requirements file
This dependency is missing and pip complains about it in
strict hashing mode. How this was missed, I have no clue.
Differential Revision: https://phab.mercurial-scm.org/D7973
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 22:23:04 -0800] rev 44232
python-zstandard: blacken at 80 characters
I made this change upstream and it will make it into the next
release of python-zstandard. I figured I'd send it Mercurial's
way because it will allow us to drop this directory from the black
exclusion list.
# skip-blame blackening
Differential Revision: https://phab.mercurial-scm.org/D7937
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Jan 2020 15:45:06 -0800] rev 44231
tests: move non-collapse test out of test-rebase-collapse
The test case was added in 76630fbbf4fa (test-rebase-collapse: Add
test for rebase regression introduced in 12309c09d19a, 2012-01-23). I
think `hg rebase --collapse` was involved in either the regression or
in the fix that caused the regression, but the test that was added
doesn't use `--collapse`, so it doesn't seem to belong in
test-rebase-collapse.t. The test case is about copies, so I moved it
to test-rebase-rename.t.
Differential Revision: https://phab.mercurial-scm.org/D7968
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:27:09 -0800] rev 44230
debugcommands: add Python implementation to debuginstall
This seems like a useful detail to print.
Differential Revision: https://phab.mercurial-scm.org/D7979
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:12:10 -0800] rev 44229
run-tests: remove --py3-warnings
This Python 2 only mode was to help Python 2 alert when doing
things not supported on Python 3. Now that we have test coverage with
Python 3, I don't think we need it.
Differential Revision: https://phab.mercurial-scm.org/D7978
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:37:05 +0100] rev 44228
rust-node: binary Node ID and conversion utilities
The choice of type makes sure that a `Node` has the exact
wanted size. We'll use a different type for prefixes.
Added dependency: hexadecimal conversion relies on the
`hex` crate.
The fact that sooner or later Mercurial is going to need
to change its hash sizes has been taken strongly in
consideration:
- the hash length is a constant, but that is not directly
exposed to callers. Changing the value of that constant
is the only thing to do to change the hash length (even
in unit tests)
- the code could be adapted to support several sizes of hashes,
if that turned out to be useful. To that effect, only the
size of a given `Node` is exposed in the public API.
- callers not involved in initial computation, I/O and FFI
are able to operate without a priori assumptions on the hash
size. The traits `FromHex` and `ToHex` have not been directly
implemented, so that the doc-comments explaining these
restrictions would stay really visible in `cargo doc`
Differential Revision: https://phab.mercurial-scm.org/D7788
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:23:29 +0100] rev 44227
rust-nodemap: building blocks for nodetree structures
This is similar to `nodetreenode` in `revlog.c`. We give it
a higher level feeling for ease of handling in Rust context
and provide tools for tests and debugging.
The encoding choice is dictated by our ultimate goal in this
series, that is to make an append-only persistent version of
`nodetree`: the 0th Block must be adressed from other Blocks.
Differential Revision: https://phab.mercurial-scm.org/D7787
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:13:08 -0500] rev 44226
lfs: move the initialization of the upload request into the try block
This (almost) guarantees that the file is closed in the case of an exception.
The one hole is if the `seek(SEEK_END)`/`tell()`/`seek(0)` sequence fails. But
that's going to go away when subclassing `httpconnection.httpsendfile` to fix
the worker problem, so I'm not going to worry too much. (And that class appears
to have the same problem.)
Differential Revision: https://phab.mercurial-scm.org/D7959
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:55:35 -0500] rev 44225
lfs: drop an unnecessary r'' prefix
No longer necessary since the source transformer was removed.
# skip-blame for changing string prefixes
Differential Revision: https://phab.mercurial-scm.org/D7958
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:51:39 -0500] rev 44224
lfs: explicitly close the file handle for the blob being uploaded
The previous code relied on reading the blob fully to close it. The obvious
problem is if an error occurs before that point. But there is also a problem
when using workers where the data may need to be re-read, which can't happen
once it is closed. This eliminates the surprising behavior before attempting to
fix the worker problem.
Differential Revision: https://phab.mercurial-scm.org/D7957
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:40:40 -0500] rev 44223
lfs: drop the unused progressbar code in the `filewithprogress` class
This has been unused since f98fac24b757, which added worker based transfers for
concurrency, shifting the progressbar maintenance to the single thread waiting
on the worker to complete. Since the name no longer fits, rename the class.
Differential Revision: https://phab.mercurial-scm.org/D7956
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 16:58:07 +0100] rev 44222
rust-filepatterns: remove bridge code for filepatterns-related functions
These functions will be used internally by `hg-core` without needed to be
exposed to Python.
Differential Revision: https://phab.mercurial-scm.org/D7868
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 18:03:28 +0100] rev 44221
rust-utils: add Rust implementation of Python's "os.path.splitdrive"
I also wrote the NT version although I didn't mean to at first, so I thought
I would keep it, so that any further effort to get the Rust code working on
Windows is a little easier.
Differential Revision: https://phab.mercurial-scm.org/D7864
Alexander Pyhalov <apyhalov@gmail.com> [Mon, 13 Apr 2020 16:30:13 +0300] rev 44220
setup: link osutil.so to libsocket on Solaris/illumos (issue6299)
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 06 Apr 2020 00:24:57 +0200] rev 44219
discovery: avoid wrongly saying there are nothing to pull
We can get in a situation where a revision passed through `hg pull --rev REV`
are available on the server, but not a descendant of the advertised server
heads.
For example the server could lying be during heads advertisement, to hide some
pull request. Or obsolete/hidden content could be explicitly pulled.
So in this case the lookup associated to `REV` returned successfully, but the
normal discovery will find all advertised heads already known locally. This flip
a special boolean `anyinc` that will prevent any fetch attempt, preventing `REV`
to be pulled over.
We add three line of code to detect this case and make sure a pull actually
happens.
My main target is to make some third party extensions happy (I expect the
associated test to move upstream with the extension). However this fix already
make some of the `infinitepush` test happier.
Augie Fackler <raf@durin42.com> [Thu, 02 Apr 2020 12:05:41 -0400] rev 44218
Added signature for changeset 8fca7e8449a8
Augie Fackler <raf@durin42.com> [Thu, 02 Apr 2020 12:05:40 -0400] rev 44217
Added tag 5.3.2 for changeset 8fca7e8449a8
Kyle Lippincott <spectral@google.com> [Wed, 01 Apr 2020 14:14:55 -0700] rev 44216
histedit: add missing b prefix to a string
If i18n is disabled (such as via HGPLAIN=1), `_()` doesn't convert from str to
bytes, so this raises a TypeError on py3.
Differential Revision: https://phab.mercurial-scm.org/D8354
Martin von Zweigbergk <martinvonz@google.com> [Wed, 25 Mar 2020 18:50:40 -0700] rev 44215
py3: require values in changelog extras to be bytes
I don't know what happened here because b436059c1cca (py3: use
pycompat.bytestr() on extra values because it can be int, 2019-02-05)
came about b44a47214122 (py3: use string for "close" value in commit
extras, 2018-02-11). Whatever happened, we shouldn't need to convert
the values to bytes now. It's better to not convert because that might
cover up bugs where someone sets a unicode value in the extras and
that works until the unicode value happens to contain non-ascii (at
which point it will fail because `bytestr()` expects its argument to
be ascii if it's unicode).
Differential Revision: https://phab.mercurial-scm.org/D8332
Martin von Zweigbergk <martinvonz@google.com> [Wed, 25 Mar 2020 18:25:58 -0700] rev 44214
py3: make setup.py's hgcommand() consistently return bytes
Before this patch, it returned unicode when the command failed. That
made e.g. `make local PYTHON=python3` fail on an obsolete commit.
Differential Revision: https://phab.mercurial-scm.org/D8331
Kyle Lippincott <spectral@google.com> [Mon, 23 Mar 2020 14:38:00 -0700] rev 44213
darwin: use vim, not vi, to avoid data-loss inducing posix behavior
Apple's version of vim, available at
opensource.apple.com/release/macos-1015.html (for Catalina, but this behavior
has been there for a while) has several tweaks from the version of vim from
vim.org. Most of these tweaks appear to be for "Unix2003" compatibility.
One of the tweaks is that if any ex command raises an error, the entire
process will (when you exit, possibly minutes/hours later) also exit non-zero.
Ex commands are things like `:foo`.
Luckily, they only enabled this if vim was executed (via a symlink or copying
the binary) as `vi` or `ex`. If you start it as `vim`, it doesn't have this
behavior, so let's do that.
To see this in action, run the following two commands on macOS:
```
$ vi -c ':unknown' -c ':qa' ; echo $?
1
$ vim -c ':unknown' -c ':qa' ; echo $?
0
```
We don't want to start ignoring non-zero return types from the editor because
that will mean you can't use `:cquit` to intentionally exit 1 (which,
shows up as 2 if you combine an ex command error and a cquit, but only a 1 if
you just use cquit, so we can't differentiate between the two statuses). Since
we can't differentiate, we have to assume that all non-zero exit codes are
intentional and an indication of the user's desire to not continue with whatever
we're doing. If this was a complicated `hg split` or `hg histedit`, this is
especially disastrous :(
Differential Revision: https://phab.mercurial-scm.org/D8321
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Mar 2020 10:04:13 -0400] rev 44212
cext: move variable declaration to the top of the block for C89 support
Not sure if we still care about C89 in general, but MSVC requires this style
too.
Differential Revision: https://phab.mercurial-scm.org/D8304
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 18 Mar 2020 21:27:45 +0100] rev 44211
byteify-string: resolve symlink before byteifying
Otherwise the script turns symlinks into regular files.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 12 Mar 2020 15:23:47 +0100] rev 44210
cext-index: propagate inline_scan error in `index_deref`
Before this change, revlog index corruption could be silently ignored in some
situation.
Differential Revision: https://phab.mercurial-scm.org/D8276
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 12 Mar 2020 18:53:37 +0100] rev 44209
heptapod-ci: fix test paths in the listing file
Now what we run the test from the root, we need to list test name from the root.
Differential Revision: https://phab.mercurial-scm.org/D8275
Raphaël Gomès <rgomes@octobus.net> [Fri, 06 Mar 2020 10:38:37 +0100] rev 44208
hg-core: add a compilation error if trying to compile outside of Linux
For now, we can only provide support for Linux in `hg-core`, so we have to be
explicit about it in case anyone wonders why their Dirstate is suddenly broken,
or why the crate does not compile (on Windows for example).
Differential Revision: https://phab.mercurial-scm.org/D8246
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 18:54:44 +0100] rev 44207
gzip: use the stdlib version with python 3 (issue6284)
It turned out that the stdlib gained the feature we missed in python 3.1. We can
now use it directly.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 18:53:19 +0100] rev 44206
gzip: indent the custom Gzip code
We need a new conditional in the next changesets (Adding 3.8 support). We do the
large code move beforehand for clarity.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 18:57:49 +0100] rev 44205
gzip: rename the argument to `mtime` to match upstream python
Python gained the feature we missed in 3.1. The argument name is `mtime`. We
align our version for consistency.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 16:49:38 +0100] rev 44204
heptapod-ci: run the test from outside the test directory
This will help detecting case where this is broken.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 10 Mar 2020 16:47:02 +0100] rev 44203
run-tests: fix conditional when tests are run outside of `tests`
The logic to find `hghave` was using `__file__` but… non absolute path in
`__file__` gets wrong as soon as we change directory (thanks python… you are
being helpful). The rest of the `run-tests.py` code already deal with this
fine. We simply reuse the `RUNTESTDIR` variable to fix it.
Manuel Jacob <me@manueljacob.de> [Mon, 09 Mar 2020 01:11:59 +0100] rev 44202
tests: fix isinstance test of wrong variable
3086a8627b2970cd7fbf49bc69413c08c68d5514 changed self._case to be a list, but
it was forgotten to adjust this line.
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Mar 2020 23:27:28 +0100] rev 44201
discovery: avoid wrong detection of multiple branch heads (issue6256)
This fix the code using obsolescence markers to remove "to be obsoleted" heads
during the detection of new head creation from push. The code turned out to not
use the branch information at all. This lead changeset from different branch to
be detected as new head on unrelated branch.
The code fix is actually quite simple. New tests have been added to covers
these cases.
Differential Revision: https://phab.mercurial-scm.org/D8259
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 06 Mar 2020 00:28:09 +0100] rev 44200
test: cleanly skip test-remotefilelog-datapack.py on policy that breaks it
That tests requires the pure module to be available.
Differential Revision: https://phab.mercurial-scm.org/D8245
Raphaël Gomès <rgomes@octobus.net> [Thu, 05 Mar 2020 09:26:45 +0100] rev 44199
rust-format: cleanup ancestors.rs to make rustfmt happy
Differential Revision: https://phab.mercurial-scm.org/D8224
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 05 Mar 2020 15:47:22 +0100] rev 44198
heptapod-ci: use strict module policy
Without this, test can silently fallback to other compatible policy in some
cases.
Differential Revision: https://phab.mercurial-scm.org/D8234
Martin von Zweigbergk <martinvonz@google.com> [Thu, 05 Mar 2020 08:30:11 -0800] rev 44197
histedit: fix formatting after D8150
Differential Revision: https://phab.mercurial-scm.org/D8230
Raphaël Gomès <rgomes@octobus.net> [Thu, 05 Mar 2020 17:17:02 +0100] rev 44196
rust-format: make rustfmt happy
Differential Revision: https://phab.mercurial-scm.org/D8228
Augie Fackler <raf@durin42.com> [Wed, 04 Mar 2020 11:51:13 -0500] rev 44195
Added signature for changeset 6d121acbb82e
Augie Fackler <raf@durin42.com> [Wed, 04 Mar 2020 11:51:12 -0500] rev 44194
Added tag 5.3.1 for changeset 6d121acbb82e
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 19 Feb 2020 13:39:00 +0530] rev 44193
remotefilelog: add 'changelog' arg to shallowcg1packer.generate (issue6269)
This cause traceback on widening using narrow extension when remotefilelog
is enabled.
Differential Revision: https://phab.mercurial-scm.org/D8134
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 28 Feb 2020 11:22:47 +0100] rev 44192
remotefilelog-test: glob some flaky output line
This is similar to ee0959e7d435. The affected line is flaky underload, yet the
final result is correct. The command involves background pre-check of output,
these are not stable probably because they run in parallel in multiple process.
If it become useful to start testing precise internal details of the, they will
have to be tested in a more appropriate framework than `.t` tests.
Differential Revision: https://phab.mercurial-scm.org/D8179
Steve Fink <sfink@mozilla.com> [Tue, 25 Feb 2020 13:23:37 -0800] rev 44191
histedit: py3 fixes for curses mode
Differential Revision: https://phab.mercurial-scm.org/D8150
Manuel Jacob <me@manueljacob.de> [Sun, 01 Mar 2020 19:39:23 +0100] rev 44190
branch: make --force work even when specifying revs
The `hg branch` command accepts a `--force` parameter that allows to
"set branch name even if it shadows an existing branch". However, before this
patch, that didn’t work when specifying revs with `-r`.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Feb 2020 00:20:47 -0500] rev 44189
setup: exclude the __index__ module from itself when generating
This module is generated on Windows to hold all of the extension names and the
help summaries, so that they are discoverable inside the py2exe zipfile. The
problem is this file is generated by dumping the disabled list, and that list
comes from walking the filesystem. So once an install from source into a
virtualenv created this module, then next build from source from that virtualenv
would also see __index__.py in the filesystem, and include it. Clearly that's
wrong because this isn't a real extension, so just filter it from the list when
generating it.
The Mercurial installer was unaffected by this, but the TortoiseHg package was.
In the final package, `hg help -v extensions` and the panel of extensions both
showed it.
Differential Revision: https://phab.mercurial-scm.org/D8142
Matt Harbison <matt_harbison@yahoo.com> [Mon, 24 Feb 2020 16:33:10 -0500] rev 44188
tests: stabilize test-amend.t on Windows
If $TESTTMP isn't quoted in this context, it ends up like
`C:Temphgtests.pikkoxchild1test-amend.t-obsstore-off`.
Differential Revision: https://phab.mercurial-scm.org/D8144
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Feb 2020 13:28:49 +0900] rev 44187
py3: fix EOL detection in commandserver.channeledinput
This breaks TortoiseHg's email preview which sends b'\n' while readline
request is issued and the loop never ends. Spotted by Matt Harbison.
Kyle Lippincott <spectral@google.com> [Thu, 20 Feb 2020 16:21:00 -0800] rev 44186
shelve: fix ordering of merge labels
Differential Revision: https://phab.mercurial-scm.org/D8140
Kyle Lippincott <spectral@google.com> [Thu, 20 Feb 2020 17:06:01 -0800] rev 44185
shelve: add test clearly demonstrating that the conflict labels are backwards
Differential Revision: https://phab.mercurial-scm.org/D8139
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Feb 2020 17:05:18 -0500] rev 44184
import: don't ignore `--secret` when `--bypass` is specified
Differential Revision: https://phab.mercurial-scm.org/D8126
Matt Harbison <matt_harbison@yahoo.com> [Tue, 18 Feb 2020 13:46:10 -0500] rev 44183
phabricator: fix a phabsend crash when processing a renamed binary
This was a trivial fix, and some more tests are added to cover binary files.
Since the old filecontext is passed in, the old name is still available. But I
noticed some weirdness around what it marked as binary and not, and what is
viewable in Phabricator. Those things have been flagged, and will probably take
some digging.
Differential Revision: https://phab.mercurial-scm.org/D8133
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Dec 2019 10:37:45 +0100] rev 44182
test: pin the number of CPU for issue4074 tests
On machine with an hundreds of CPUs, the "user" CPU time reported can be
inflated by the status steps. Since the test especially focus on the diff
computation, we restrict the number of CPU to avoid potential issues.
Differential Revision: https://phab.mercurial-scm.org/D8112
Raphaël Gomès <rgomes@octobus.net> [Wed, 12 Feb 2020 23:23:59 +0100] rev 44181
rust-dirstatemap: add `NonNormalEntries` class
This fix introduces the same encapsulation as the `copymap`. There is no easy
way of doing this any better for now.
`hg up -r null && time HGRCPATH= HGMODULEPOLICY=rust+c hg up tip` on Mozilla
Central, (not super recent, but it doesn't matter):
Before: 7:44,08 total
After: 1:03,23 total
Pretty brutal regression!
This is a graft on stable of cf1f8660e568
Differential Revision: https://phab.mercurial-scm.org/D8111
Raphaël Gomès <rgomes@octobus.net> [Thu, 30 Jan 2020 14:57:02 +0100] rev 44180
rust-dirstatemap: cache non normal and other parent set
Performance of `hg update` was significantly worse since the introduction of
the Rust `dirstatemap`. This regression was noticed by Valentin Gatien-Baron
when working on a large repository, as it goes unnoticed for smaller
repositories like Mercurial itself.
This fix introduces the same getter/setter mechanism at `hg-core` level as
for `set/get_dirs`.
While this technique is, as previously discussed, quite suboptimal, it fixes an
important enough problem. Refactoring `hg-core` to use the typestate
pattern could be a good approach to improving code quality in a future patch.
This is a graft of stable of 83b2b829c94e
Differential Revision: https://phab.mercurial-scm.org/D8110
Yuya Nishihara <yuya@tcha.org> [Tue, 11 Feb 2020 19:53:56 +0900] rev 44179
chgserver: spawn new process if schemes change
The schemes extension updates hg.schemes table. It's technically possible
for hg.repository() to look for e.g. ui.schemes instead of depending on
module-local table, but I don't think the change would make much sense
since [schemes] is usually specified in ~/.hgrc and thus it can be considered
static data.
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Feb 2020 15:52:52 -0800] rev 44178
tests: accept new bzr message about switching branches
The new version apparently prints "Switched to branch at " instead of
"Switched to branch: ".
Differential Revision: https://phab.mercurial-scm.org/D8106
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Feb 2020 15:50:26 -0800] rev 44177
tests: add workaround for bzr bug
This started failing for me today. I guess my bzr was upgraded.
Differential Revision: https://phab.mercurial-scm.org/D8105
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Feb 2020 09:14:36 +0100] rev 44176
test: simplify test-amend.t to avoid race condition
Insted on relying on sleep, we could simply have the editor do the file change.
This remove the reliance on "sleep" and avoid test failing on heavy load
machine.
To test this, I reverted the code change in 5558e3437872 and the test started
failing again.
This is a graft on stable of 141ceec06b55 which should have targeted for stable.
Differential Revision: https://phab.mercurial-scm.org/D8103
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 09 Feb 2020 01:34:37 +0100] rev 44175
remotefilelog-test: glob some flaky output line (issue6083)
The two following lines are flaky underload, yet the final result is correct.
The command involves background pre-check of output, these are not stable
probably because they run in parallel in multiple process.
I spent a couple of hours trying to understand the pattern and gave up. The
documented intend of these tests is safely guaranteed by checking the cache
content after the command.
If it become useful to start testing precise internal details of the, they will
have to be tested in a more appropriate framework than `.t` tests.
Differential Revision: https://phab.mercurial-scm.org/D8102
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 11:56:02 -0500] rev 44174
resourceutil: blacken
Kyle Lippincott <spectral@google.com> [Thu, 06 Feb 2020 15:46:55 -0800] rev 44173
py3: fully fix bundlepart.__repr__ to return str not bytes
My previous fix did not fully fix the issue: it would attempt to use
%-formatting to combine two strs into a bytes, which won't work. Let's just
switch the entire function to operating in strs. This can cause a small output
difference that will likely not be noticed since no one noticed that the method
wasn't working at all before: if `id` or `type` are not-None, they'll be shown
as `b'val'` instead of `val`. Since this is a debugging aid and these strings
shouldn't be shown to the user, slightly rough output is most likely fine and
it's likely not worthwhile to add the necessary conditionals to marginally
improve it.
Differential Revision: https://phab.mercurial-scm.org/D8091
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 17 Nov 2019 01:18:14 +0100] rev 44172
heptapod-ci: add a job to test the rust version of Mercurial
The rust version of Mercurial is not currently tested by anything else. So it
get quite important that developer runs it.
Differential Revision: https://phab.mercurial-scm.org/D8017
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Nov 2019 12:26:54 +0100] rev 44171
heptapod-ci: run the --pure test too
These are usually rarely run by individual developper because they are slow.
However it is important that they stay happy.
Differential Revision: https://phab.mercurial-scm.org/D8016
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 25 Jan 2020 14:56:36 +0100] rev 44170
heptapod-ci: run the normal test suite
The usual tests should be run too. We skip the "tests-check*.t" one because
their are already covered by another Ci step.
Differential Revision: https://phab.mercurial-scm.org/D8015
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Nov 2019 09:38:40 +0100] rev 44169
heptapod-ci: also run the dedicated rust test for the rust code
The Rust code has various standard rust test that are fast to run. So let's run them.
Differential Revision: https://phab.mercurial-scm.org/D8014
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Nov 2019 12:25:53 +0100] rev 44168
heptapod-ci: run test with python3 too
Python3 is the future^W present, it is important to run tests with it too.
Differential Revision: https://phab.mercurial-scm.org/D8013
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Jan 2020 23:22:29 +0100] rev 44167
heptapod-ci: colorize output
The run result are nicer to read with color.
Differential Revision: https://phab.mercurial-scm.org/D8012
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 25 Jan 2020 17:57:40 +0100] rev 44166
heptapod-ci: add a basic file to be able to run tests with heptapod
Having this yaml file somewhere in the main mercurial repository makes it
trivial for contributors using heptapod to run CI on their in-progress work.
There are alot of different combination (python2/python3 pure/cext/rust/pypy)
to be tested and making sure all of them are covered manually is cumbersome.
Automatic CI runnig on draft really helps in that matters. We start small bu
later changesets will add more step testing more of the variants.
The series is targetted on stable to make it available to the widest amount of contribution possible.
The definition of the docker files used for this are available here:
https://dev.heptapod.net/octobus/ci-dockerfiles
Differential Revision: https://phab.mercurial-scm.org/D8011
Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> [Tue, 04 Feb 2020 22:07:36 +0100] rev 44165
worker: manually buffer reads from pickle stream
My previous fix (D8051, cb52e619c99e, which added Python's built-in buffering
to the pickle stream) has the problem that the selector will ignore the buffer.
When multiple pickled objects are read from the pipe into the buffer at once,
only one object will be loaded.
This can repeat until the buffer is full and delays the processing of completed
items until the worker exits, at which point the pipe is always considered
readable and all remaining items are processed.
This changeset reverts D8051, removing the buffer again. Instead, on Python 3
only, we use a wrapper to modify the "read" provided to the Unpickler to behave
more like a buffered read. We never read more bytes from the pipe than the
Unpickler requests, so the selector behaves as expected.
Also add a test case for "pickle data was truncated" issue.
https://phab.mercurial-scm.org/D8051#119193
Differential Revision: https://phab.mercurial-scm.org/D8076
Kyle Lippincott <spectral@google.com> [Thu, 02 Jan 2020 11:04:18 -0800] rev 44164
py3: __repr__ needs to return str, not bytes
Differential Revision: https://phab.mercurial-scm.org/D8089
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 04 Feb 2020 12:07:37 +0100] rev 44163
config: also respect HGRCSKIPREPO in the zeroconf extension
Differential Revision: https://phab.mercurial-scm.org/D8075
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 04 Feb 2020 12:07:42 +0100] rev 44162
config: also respect HGRCSKIPREPO in hgwebdir_mod
Differential Revision: https://phab.mercurial-scm.org/D8074
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 03 Feb 2020 20:41:11 +0100] rev 44161
config: also respect HGRCSKIPREPO in `dispatch._getlocal`
For some reason, we are also reading the local config in that function.
Differential Revision: https://phab.mercurial-scm.org/D8073
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 04 Feb 2020 12:31:19 +0100] rev 44160
config: add a function in `rcutil` to abstract HGRCSKIPREPO
We wil need to respect this environment variable in more place.
Differential Revision: https://phab.mercurial-scm.org/D8072
Matt Harbison <matt_harbison@yahoo.com> [Mon, 03 Feb 2020 20:12:47 -0500] rev 44159
packaging: make the path to Win32 requirements absolute when building WiX
Otherwise this broke automation when not launched from `contrib/packaging`.
Differential Revision: https://phab.mercurial-scm.org/D8068
Augie Fackler <raf@durin42.com> [Mon, 03 Feb 2020 11:07:34 -0500] rev 44158
Added signature for changeset 7f5410dfc8a6
Augie Fackler <raf@durin42.com> [Mon, 03 Feb 2020 11:07:33 -0500] rev 44157
Added tag 5.3 for changeset 7f5410dfc8a6
Raphaël Gomès <rgomes@octobus.net> [Wed, 29 Jan 2020 11:11:18 +0100] rev 44156
rust-dirstatemap: add missing @propertycache
While investigating a regression on `hg update` performance introduced by the
Rust `dirstatemap`, two missing `@propertycache` were identified when comparing
against the Python implementation. This adds back the first one, that has
no observable impact on behavior. The second one (`nonnormalset`) is going to
be more involved, as the caching has to be done from the Rust side of things.
Differential Revision: https://phab.mercurial-scm.org/D8047
Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> [Thu, 30 Jan 2020 19:16:12 +0100] rev 44155
worker: Use buffered input from the pickle stream
On Python 3, "pickle.load" will raise an exception ("_pickle.UnpicklingError:
pickle data was truncated") when it gets a short read, i.e. it receives fewer
bytes than it requested.
On our build machine, Mercurial seems to frequently hit this problem while
updating a mozilla-central clone iff it gets scheduled in batch mode. It is easy
to trigger with:
#wipe the workdir
rm -rf *
hg update null
chrt -b 0 hg update default
I've also written the following program, which demonstrates the core problem:
from __future__ import print_function
import io
import os
import pickle
import time
obj = {"a": 1, "b": 2}
obj_data = pickle.dumps(obj)
assert len(obj_data) > 10
rfd, wfd = os.pipe()
pid = os.fork()
if pid == 0:
os.close(rfd)
for _ in range(4):
time.sleep(0.5)
print("First write")
os.write(wfd, obj_data[:10])
time.sleep(0.5)
print("Second write")
os.write(wfd, obj_data[10:])
os._exit(0)
try:
os.close(wfd)
rfile = os.fdopen(rfd, "rb", 0)
print("Reading")
while True:
try:
obj_copy = pickle.load(rfile)
assert obj == obj_copy
except EOFError:
break
print("Success")
finally:
os.kill(pid, 15)
The program reliably fails with Python 3.8 and succeeds with Python 2.7.
Providing the unpickler with a buffered reader fixes the issue, so let
"os.fdopen" create one.
https://bugzilla.mozilla.org/show_bug.cgi?id=1604486
Differential Revision: https://phab.mercurial-scm.org/D8051
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 01:32:28 -0500] rev 44154
packaging: lowercase the `contrib` and `templates` directories with Inno
I have no idea why these (and `contrib/vim`) were leading with uppercase with
Inno, but not WiX. It probably doesn't matter too much, but might be a problem
with `templates` if the user enabled case sensitivity on NTFS.
Differential Revision: https://phab.mercurial-scm.org/D8063
Matt Harbison <matt_harbison@yahoo.com> [Sun, 02 Feb 2020 00:56:40 -0500] rev 44153
packaging: merge the requirements.txt files for WiX and Inno
Now that the content is common, there's no need to have separate files. The
content still differs from the non-Windows platforms though.
Differential Revision: https://phab.mercurial-scm.org/D8066
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:58:34 -0500] rev 44152
packaging: bundle dulwich, keyring, and pywin32-ctypes with WiX too
TortoiseHg installs these, which is possibly where they originated (though I
would have thought it more likely to be in the WiX installer, given its
heritage). When I was working on the TortoiseHg app for Mac (which uses the
similar `py2app`), it wasn't possible to use the keyring extension (even
externally) without bundling this keyring package into the app. Assuming the
same principle applies here, these would enable some common extensions. One of
the things that the TortoiseHg packager on macOS does now is it adds the user's
local `site-packages` directory to `sys.path`. That would allow the user to
install these critical modules in cases like this. But that can probably wait
for py3 packaging.
The only difference in the installed packages that I see now is WiX also bundles
distutils for some reason. I suppose that's not harming anything, so I'm not
touching it.
The only orphans in the install directories when comparing WiX and Inno now is
the Copying.txt vs COPYING.rtf, the two uninstaller files for Inno, and a
`Mercurial.url` file in Inno. I have no idea what that is, and it has *.ini
syntax with a single field pointing to the Mercurial homepage.
Differential Revision: https://phab.mercurial-scm.org/D8062
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:48:08 -0500] rev 44151
packaging: bundle the default mercurial.ini template with Inno also
This is a step towards converging on the same installer content on Windows.
Differential Revision: https://phab.mercurial-scm.org/D8061
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:41:37 -0500] rev 44150
packaging: set the FileVersion field in the Inno installer executable
Previously, Properties > Details > File version showed "0.0.0.0". This appears
to be a longstanding issue, and not part of the refactoring this cycle.
Differential Revision: https://phab.mercurial-scm.org/D8060
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:32:46 -0500] rev 44149
packaging: move the version normalization function to the util module
This will be used with Inno as well. Since this module isn't platform specific,
rename to include that this is meant for Windows. (Mac has a different format.)
Differential Revision: https://phab.mercurial-scm.org/D8059
Matt Harbison <matt_harbison@yahoo.com> [Fri, 31 Jan 2020 22:20:39 -0500] rev 44148
resourceutil: account for the non-resource-like file hierarchy under py2exe
After 9e367157a990, config files for py2exe were expected to be in
C:\Program Files\Mercurial\mercurial\defaultrc because of the implied resource
structure of 'mercurial.defaultrc.*.rc', relative to the executable.
Accomodating this would require changes to the WIX and Inno scripts (and perhaps
the script that generates the WIX script), as well as 3rd party bundlers like
TortoiseHg. But these files aren't read as resources anyway- they fall back to
the filesystem APIs. (If we really wanted to carry on the charade, the
installer would have to also sprinkle various empty __init__.py files around.)
Instead, this simply prunes the 'mercurial.' portion of the resource name when
run with py2exe. (PyOxidizer uses the resources API, not the filesystem
fallback, so it is unaffected.) Since this hack only affects the py2 Windows
installers and is less risky, I think it's reasonable. We haven't needed to
load any 3rd party resource up to this point, and would have to make packaging
changes anyway to handle that.
Differential Revision: https://phab.mercurial-scm.org/D8058
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 19:37:06 -0500] rev 44147
wix: restore COPYING.rtf
This got truncated to 0 bytes in 0ab651b5f77c when the Phabricator extension
crashed because it's a binary file. That caused the license page in the WIX
installer to be empty. I don't remember if I needed to resubmit after the bug
was fixed, so let's try this again with the current stable. If this fails, I'll
retry with 5.1 to see if this is a regression in the API changeover last cycle.
Differential Revision: https://phab.mercurial-scm.org/D8052
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 23:48:45 -0500] rev 44146
resourceutil: correct the root path for file based lookup under py2exe
This silly copy/paste error caused "Mercurial" to be truncated from
"C:\Program Files". The fact that "helptext" and "defaultrc" are now in a
subpackage of "mercurial" added it back on, and everything seemed to work. But
that broke if not installed to the default directory, and also caused TortoiseHg
to look at Mercurial's config files instead of its own.
Differential Revision: https://phab.mercurial-scm.org/D8054
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Jan 2020 20:27:59 -0800] rev 44145
wix: use original version string for MSI filename
Version string normalization is mostly to placate MSI requirements.
I think it makes sense to use the original version string in
filenames.
Since we can have distinct versions normalizing to the same MSI
version string, this will allow us to distinguish between different
actual version strings based on the filename.
Differential Revision: https://phab.mercurial-scm.org/D8005
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Jan 2020 20:24:29 -0800] rev 44144
wix: always normalize version string
Before, it was possible to pass in a custom version string
which would not be valid in MSI. So we always normalize the
version string.
While we're here, also print when we normalize the version string,
for better visibility.
Differential Revision: https://phab.mercurial-scm.org/D8004
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Jan 2020 20:21:53 -0800] rev 44143
wix: more robust normalization of RC version components
MSI has strict version requirements where the format is
`A.B.C[.D]` and all fields must be numeric
(https://docs.microsoft.com/en-us/windows/win32/msi/productversion?redirectedfrom=MSDN).
Only the first 3 are used by the installer itself.
Mercurial's version strings can have `rcN` and an optional
`+<commit>-<date>` fragment at the end.
This commit teaches the MSI version normalization to handle
both of these more robustly.
Before, we would throw away the `.rcN` component completely.
e.g. `5.3rc1` would get normalized to `5.3.0`. And worse,
`5.3rc0+5-abcdef` would get normalized to `5.3.5`.
After this commit, presence of an `.rcN` provides the
value for a 4th field. e.g. `5.3rc1` -> `5.3.0.1`. In
addition, the commit count from the `+` suffix gets
normalized into the 4th version component, but only if
the original version string didn't have a 4th version
component or if no `rcN` is present. e.g. `5.3+5-abcdef`
is `5.3.0.5`.
Differential Revision: https://phab.mercurial-scm.org/D8003
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Jan 2020 00:16:04 -0500] rev 44142
copyright: update to 2020
Differential Revision: https://phab.mercurial-scm.org/D8006
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Jan 2020 01:06:46 -0500] rev 44141
phabricator: fix a crash when submitting binaries (issue6260)
I think this assumed that `p1()` returned the changectx instead of the previous
filelog entry.
Differential Revision: https://phab.mercurial-scm.org/D8010
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 20:01:38 -0800] rev 44140
packaging: add configparser to inno requirements file
This dependency is missing and pip complains about it in
strict hashing mode. How this was missed, I have no clue.
Differential Revision: https://phab.mercurial-scm.org/D7973
Augie Fackler <raf@durin42.com> [Fri, 24 Jan 2020 11:02:59 -0500] rev 44139
Added signature for changeset e4344e463c0c
Augie Fackler <raf@durin42.com> [Fri, 24 Jan 2020 11:02:58 -0500] rev 44138
Added tag 5.3rc1 for changeset e4344e463c0c
Matt Harbison <matt_harbison@yahoo.com> [Fri, 24 Jan 2020 01:37:18 -0500] rev 44137
packaging: rename hgrc.d to defaultrc for Windows config files next to the exe
The code and the help still says that it will read hgrc.d next to the
executable. But this directory needs to exist to read the resource based config
files. Otherwise even `hg version` errors out:
$ /c/Program\ Files/Mercurial/hg.exe version
Traceback (most recent call last):
File "hg", line 43, in <module>
File "mercurial\dispatch.pyc", line 110, in run
File "mercurial\dispatch.pyc", line 226, in dispatch
File "mercurial\ui.pyc", line 308, in load
File "mercurial\rcutil.pyc", line 99, in rccomponents
File "mercurial\rcutil.pyc", line 69, in default_rc_resources
File "mercurial\utils\resourceutil.pyc", line 84, in contents
WindowsError: [Error 3] The system cannot find the path specified: 'c:\\Program Files\\mercurial\\defaultrc\\*.*'
Differential Revision: https://phab.mercurial-scm.org/D7981
Matt Harbison <matt_harbison@yahoo.com> [Fri, 24 Jan 2020 01:11:19 -0500] rev 44136
resourceutil: ensure `_rootpath` is defined under py2exe
Can't even run `hg version` without this.
Differential Revision: https://phab.mercurial-scm.org/D7980
Kyle Lippincott <spectral@google.com> [Tue, 21 Jan 2020 17:15:34 -0800] rev 44135
crecord: fix a concatenation of bytes and str on py3
Differential Revision: https://phab.mercurial-scm.org/D7970
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 22 Jan 2020 14:11:11 -0500] rev 44134
recover: fix typos
Differential Revision: https://phab.mercurial-scm.org/D7971