Wed, 22 Jan 2020 15:20:12 -0800 copies: move early return in mergecopies() earlier
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:20:12 -0800] rev 44162
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
Fri, 24 Jan 2020 07:00:45 -0800 tests: test merge of renames of different sources to same target
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 07:00:45 -0800] rev 44161
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
Fri, 24 Jan 2020 09:33:02 -0800 clean: check that there are no conflicts after
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 09:33:02 -0800] rev 44160
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
Fri, 24 Jan 2020 14:32:53 -0800 progress: delete deprecated ui.progress()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 14:32:53 -0800] rev 44159
progress: delete deprecated ui.progress() Differential Revision: https://phab.mercurial-scm.org/D7991
Fri, 17 Jan 2020 15:34:11 +0100 rust-dependencies: update rayon
Raphaël Gomès <rgomes@octobus.net> [Fri, 17 Jan 2020 15:34:11 +0100] rev 44158
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
Wed, 22 Jan 2020 20:01:38 -0800 packaging: add configparser to inno requirements file stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 20:01:38 -0800] rev 44157
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
Fri, 24 Jan 2020 11:05:42 -0500 merge with stable
Augie Fackler <augie@google.com> [Fri, 24 Jan 2020 11:05:42 -0500] rev 44156
merge with stable
Fri, 24 Jan 2020 11:02:59 -0500 Added signature for changeset e4344e463c0c stable
Augie Fackler <raf@durin42.com> [Fri, 24 Jan 2020 11:02:59 -0500] rev 44155
Added signature for changeset e4344e463c0c
Fri, 24 Jan 2020 11:02:58 -0500 Added tag 5.3rc1 for changeset e4344e463c0c stable
Augie Fackler <raf@durin42.com> [Fri, 24 Jan 2020 11:02:58 -0500] rev 44154
Added tag 5.3rc1 for changeset e4344e463c0c
Fri, 24 Jan 2020 01:37:18 -0500 packaging: rename hgrc.d to defaultrc for Windows config files next to the exe stable 5.3rc1
Matt Harbison <matt_harbison@yahoo.com> [Fri, 24 Jan 2020 01:37:18 -0500] rev 44153
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
Fri, 24 Jan 2020 01:11:19 -0500 resourceutil: ensure `_rootpath` is defined under py2exe stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 24 Jan 2020 01:11:19 -0500] rev 44152
resourceutil: ensure `_rootpath` is defined under py2exe Can't even run `hg version` without this. Differential Revision: https://phab.mercurial-scm.org/D7980
Wed, 15 Jan 2020 15:08:42 -0800 merge: define updatedirstate a little earlier and reuse it
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:08:42 -0800] rev 44151
merge: define updatedirstate a little earlier and reuse it Differential Revision: https://phab.mercurial-scm.org/D7899
Wed, 15 Jan 2020 15:07:43 -0800 merge: don't call update hook when using in-memory context
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:07:43 -0800] rev 44150
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
Thu, 23 Jan 2020 13:10:48 -0800 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 13:10:48 -0800] rev 44149
merge with stable
Wed, 22 Jan 2020 20:01:38 -0800 packaging: add configparser to inno requirements file
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 20:01:38 -0800] rev 44148
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
Wed, 22 Jan 2020 22:23:04 -0800 python-zstandard: blacken at 80 characters
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 22:23:04 -0800] rev 44147
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
Tue, 21 Jan 2020 15:45:06 -0800 tests: move non-collapse test out of test-rebase-collapse
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Jan 2020 15:45:06 -0800] rev 44146
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
Fri, 22 Nov 2019 20:27:09 -0800 debugcommands: add Python implementation to debuginstall
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:27:09 -0800] rev 44145
debugcommands: add Python implementation to debuginstall This seems like a useful detail to print. Differential Revision: https://phab.mercurial-scm.org/D7979
Fri, 22 Nov 2019 20:12:10 -0800 run-tests: remove --py3-warnings
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:12:10 -0800] rev 44144
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
Wed, 22 Jan 2020 16:37:05 +0100 rust-node: binary Node ID and conversion utilities
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:37:05 +0100] rev 44143
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
Wed, 22 Jan 2020 16:23:29 +0100 rust-nodemap: building blocks for nodetree structures
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:23:29 +0100] rev 44142
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
Tue, 21 Jan 2020 10:13:08 -0500 lfs: move the initialization of the upload request into the try block
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:13:08 -0500] rev 44141
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
Tue, 21 Jan 2020 09:55:35 -0500 lfs: drop an unnecessary r'' prefix
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:55:35 -0500] rev 44140
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
Tue, 21 Jan 2020 09:51:39 -0500 lfs: explicitly close the file handle for the blob being uploaded
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:51:39 -0500] rev 44139
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
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -24 +24 +50 +100 +300 +1000 +3000 tip