transaction: tests we don't overwrite updates on abort spoiler: we do… /o\

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‽

transaction: tests we don't overwrite tracking to changed file on abort spoiler: we do…

transaction: the base of a new test file checking transaction abort issue See inline documentation for details. See other changesets for actual cases.

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.

rhg: in path_encode, simplify a bit more Use the slices for `basename` and `ext` instead of dealing with offsets.

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.

rhg: small refactor: stop using a magical constant "+ 1" Instead, directly do what the "+ 1" was supposed to achive: call hash_encode.

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.

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.

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.

rhg: in path_encode, make DestArr generic over its size

rhg: in path_encode add a DestArr type This is an implementation of Sink trait that writes into a fixed-size buffer on the stack, so identical to what was done before, but it makes the code of [hash_encode] easier to understand by dropping all these slice manipulations.

rhg: reduce verbosity in path_encode by using a trait for writing Hopefully this makes the code easier to read and understand and shorter overall. It also lets us later tweak the type we use as a [Sink], without having to change the encoding functions, including using two different types for size measurement and for the actual serialization.

refactor: simplify code in rust version of path_encode Moving the addition of '/' separator to the end of the loop makes the rest of the logic much simpler because the first iteration is no longer special.

dirstate: phase-divergent update to 4e95341c89aa Heptapod published the obsolete version of those.

dirstate: phase-divergent update to 65943224c184 Heptapod published the obsolete version of those.

dirstate: phase-divergent update to 3433723d1b9b Heptapod published the obsolete version of those.

dirstate: enforce change context for hacky_extension_update_file This was the last method not scoped yet

large-files: use a `changing_files` context when initializing the dirstate We are obviously mutating the dirstate, so lets scope this mutation.

dirstate: enforce context set_clean and set_possibly_dirty We don't want them called within a `changing_parents` context, but we still want them called within a context. So we update the decorator accordingly

keyword: wrap dirstate mutation in `changing_files` context This is the way.

keyword: wrap dirstate mutation in `changing_files` context This is the way.

dirstate: enforce `running_status` context for calling `status` Now that the context is working as intended and that the callers are updated. We can enforce it.

dirstate: have `running_status` warn when exiting with a dirty dirstate If running_status was started without the lock, all changes should have been explicitly written (with the lock) or invalidated before exiting the context.

dirstate: have `running_status` write the dirstate when holding the lock This is simple and harmless.

dirstate: check that dirstate is clean at the initial context opening More checking that we are not doing anything weird.

dirstate: start tracking that we are within a `running_status` context