Wed, 22 Feb 2023 18:07:34 +0100 transaction: tests we don't overwrite branch changes on abort stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:07:34 +0100] rev 50171
transaction: tests we don't overwrite branch changes on abort We actually do not! Great. …Why are doing a backup of the `branch` files at transaction creation then‽
Wed, 22 Feb 2023 18:05:36 +0100 transaction: tests we don't overwrite tracking to changed file on abort stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:05:36 +0100] rev 50170
transaction: tests we don't overwrite tracking to changed file on abort spoiler: we do…
Wed, 22 Feb 2023 18:03:18 +0100 transaction: the base of a new test file checking transaction abort issue stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:03:18 +0100] rev 50169
transaction: the base of a new test file checking transaction abort issue See inline documentation for details. See other changesets for actual cases.
Wed, 22 Feb 2023 18:30:47 +0100 setup: support building from an ongoing merge stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:30:47 +0100] rev 50168
setup: support building from an ongoing merge Before this change the two parents from the merge would duplicate some command output and modify some others in a way python 3.11 chokes on.
Fri, 17 Feb 2023 16:48:11 +0000 rhg: in path_encode, simplify a bit more
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 17 Feb 2023 16:48:11 +0000] rev 50167
rhg: in path_encode, simplify a bit more Use the slices for `basename` and `ext` instead of dealing with offsets.
Fri, 17 Feb 2023 13:29:39 +0000 rhg: in path_encode, be a bit more conservative about memory usage
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 17 Feb 2023 13:29:39 +0000] rev 50166
rhg: in path_encode, be a bit more conservative about memory usage Use [shrink_to_fit] to match the previous behavior more closely, and potentially save (a tiny bit) of memory. FWIW, I suspect this is unnecessary, but this whole MR is about simplifying things while preserving any existing optimizations.
Thu, 16 Feb 2023 19:14:51 +0000 rhg: small refactor: stop using a magical constant "+ 1"
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 19:14:51 +0000] rev 50165
rhg: small refactor: stop using a magical constant "+ 1" Instead, directly do what the "+ 1" was supposed to achive: call hash_encode.
Thu, 16 Feb 2023 19:03:17 +0000 rhg: in path_encode, use Vec directly instead of VecDest
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 19:03:17 +0000] rev 50164
rhg: in path_encode, use Vec directly instead of VecDest No need to have a trivial wrapper over the type. There's nothing confusing about vec.write_bytes(...), after all.
Thu, 16 Feb 2023 19:00:56 +0000 rhg: in path_encode, split Dest into VecDest and MeasureDest
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 19:00:56 +0000] rev 50163
rhg: in path_encode, split Dest into VecDest and MeasureDest Two separate types make the write semantics easier to understand because we can consider the two sinks separately. Having two independent compiled functions for size measurement and for actual encoding seems likely to improve performance, too. (and maybe we should get rid of measurement altogether) Getting rid of [Dest] also removes the ugly option rewrapping code, which is good.
Thu, 16 Feb 2023 18:46:44 +0000 rhg: use generic DestArr in hash_mangle
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 18:46:44 +0000] rev 50162
rhg: use generic DestArr in hash_mangle This simplifies code a bit more, but comes with an extra memory copy in case [destlen == dest_vec.len()]. This is probably fine, but a follow-up change is removing that too.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip