Sun, 13 Oct 2019 21:47:05 +0900 rust-cpython: drop direct dependency on python(27|3)_sys
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 21:47:05 +0900] rev 43214
rust-cpython: drop direct dependency on python(27|3)_sys We no longer use it.
Sun, 13 Oct 2019 17:07:44 +0900 rust-cpython: leverage upstreamed py_capsule_fn!() macro
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 17:07:44 +0900] rev 43213
rust-cpython: leverage upstreamed py_capsule_fn!() macro
Sun, 13 Oct 2019 17:05:09 +0900 rust-cpython: bump cpython crates to 0.3
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 17:05:09 +0900] rev 43212
rust-cpython: bump cpython crates to 0.3 Unblocks py_capsule_fn!().
Sun, 13 Oct 2019 17:02:26 +0900 rust-cpython: turn inline comments into non-doc comments
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 17:02:26 +0900] rev 43211
rust-cpython: turn inline comments into non-doc comments
Sun, 13 Oct 2019 17:01:10 +0900 rust-cpython: fix signature of make_dirstate_tuple()
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 17:01:10 +0900] rev 43210
rust-cpython: fix signature of make_dirstate_tuple() Fortunately, the layout of PyObject {} is compatible with a C pointer, but we shouldn't rely on that. This also fixes the handling of NULL pointer.
Sun, 13 Oct 2019 16:58:15 +0900 rust-cpython: mark capsule function as unsafe
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 16:58:15 +0900] rev 43209
rust-cpython: mark capsule function as unsafe
Sun, 13 Oct 2019 16:55:17 +0900 rust-cpython: add wrapper around decapsule_make_dirstate_tuple()
Yuya Nishihara <yuya@tcha.org> [Sun, 13 Oct 2019 16:55:17 +0900] rev 43208
rust-cpython: add wrapper around decapsule_make_dirstate_tuple() There are a couple of safety issues. First, the returned function pointer must be unsafe. Second, its return value must be a raw pointer (i.e. python27_sys::PyObject), not a cpython::PyObject. The wrapper function will address these issues.
Sun, 13 Oct 2019 02:10:26 +0200 eol: don't fallback to use .hgeol from tip (BC)
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 02:10:26 +0200] rev 43207
eol: don't fallback to use .hgeol from tip (BC) If no .hgeol were found in the current working directory, eol would fallback to use the one in tip. That could in some cases give very confusing or wrong behaviour when it applied wrong filters. It might be convenient to have plain 'clone' immediately apply 'native' encoding patterns in the cloned repo. But it is wrong to assume that this revision is tip, and even more wrong to also apply it when not cloning - for example when updating between history revisions. The encoding should always match the content of the current .hgeol . It should never use anything else.
Mon, 14 Oct 2019 01:42:24 +0200 eol: tweak test-eol-clone.t with better descriptions and logging
Mads Kiilerich <mads@kiilerich.com> [Mon, 14 Oct 2019 01:42:24 +0200] rev 43206
eol: tweak test-eol-clone.t with better descriptions and logging Expose impact of changes coming next ...
Sun, 13 Oct 2019 02:15:07 +0200 eol: fix update - don't use and apply removed .hgeol patterns
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 02:15:07 +0200] rev 43205
eol: fix update - don't use and apply removed .hgeol patterns 'hg up -C' to revisions with different .hgeol patterns could leave dirty changes in the working directory. That could make deployment of new .hgeol filters tricky: they would "occasionally" apply also in branches where they shouldn't. Fixed by dropping all old patterns before applying new ones.
Sun, 13 Oct 2019 02:11:33 +0200 eol: cache needs update, also if it has same timestamp as the source
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 02:11:33 +0200] rev 43204
eol: cache needs update, also if it has same timestamp as the source Ignoring same timestamp could (in theory?) cause changes to not be detected. It might happen quite often that the cache is populated right after .hgeol has been updated and they thus have the same time stamp second. But we want correctness, and if it populates the cache so fast, then it can also not be a big problem to run it again next time when the timestamp has moved on.
Mon, 14 Oct 2019 01:33:18 +0200 eol: update isbinary filter to work without compat wrapper
Mads Kiilerich <mads@kiilerich.com> [Mon, 14 Oct 2019 01:33:18 +0200] rev 43203
eol: update isbinary filter to work without compat wrapper
Sun, 13 Oct 2019 02:05:19 +0200 localrepo: fix variable binding in handling of old filters
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 02:05:19 +0200] rev 43202
localrepo: fix variable binding in handling of old filters The lambda was referencing oldfn in outer scope without binding the current value. If oldfn function were reassigned before use, wrong filters could be used. Fixed by having oldfn as named parameter default value of the lambda.
Sun, 13 Oct 2019 14:40:00 +0200 localrepo: debug log of filter name when filtering through a function
Mads Kiilerich <mads@kiilerich.com> [Sun, 13 Oct 2019 14:40:00 +0200] rev 43201
localrepo: debug log of filter name when filtering through a function
Mon, 14 Oct 2019 00:09:25 +0200 eol: test-eol-update.t coverage around update --clean using filters ... badly
Mads Kiilerich <mads@kiilerich.com> [Mon, 14 Oct 2019 00:09:25 +0200] rev 43200
eol: test-eol-update.t coverage around update --clean using filters ... badly This will reveal problems and track their fixes.
Thu, 10 Oct 2019 17:18:46 +0200 copies: drop the findlimit logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 10 Oct 2019 17:18:46 +0200] rev 43199
copies: drop the findlimit logic We don't use the limit anymore so we should stop computing that limit. I did not bother measuring the potential performance gain. I am assuming that not running any code will be faster that doing some computation and not using the result.
(0) -30000 -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 tip