dirstate-v2: Reuse existing paths when appending to a data file When writing a dirstate in v2 format by appending to an existing data file, filenames / paths that are borrowed from the previous on-disk representation can be reused. Differential Revision: https://phab.mercurial-scm.org/D11096

dirstate-v2: Reuse existing nodes when appending to a data file When writing a dirstate in v2 format by appending to an existing data file, nodes that are still "unparsed" from the previous on-disk representation have been unchanged and can therefore be reused. This makes the new data point to previously-existing data for tree nodes. Differential Revision: https://phab.mercurial-scm.org/D11095

dirstate-v2: Support appending to the same data file For now we’re still writing the entire data every time, so appending is not useful yet. Later we’ll have new nodes pointing to some existing data for nodes and paths that haven’t changed. The decision whether to append is pseudo-random in order to make tests exercise both code paths. This will be replaced by a heuristic based on the amount of unused existing data. Differential Revision: https://phab.mercurial-scm.org/D11094

dirstate-v2: shrink on-disk path lengths to 16-bits Differential Revision: https://phab.mercurial-scm.org/D11091

dirstate-v2: Rename Header to Root, move it to the end of the data file Now that they don’t have to be at the start, a given data file may contain multiple "roots". A docket only points to one of them, and previous ones are left unused to allow allow append-only in-place writing to an existing data file. Differential Revision: https://phab.mercurial-scm.org/D11090

dirstate-v2: Enforce data size read from the docket file The data file may not be shorter than its size given by the docket. It may be longer, but additional data is ignored. Differential Revision: https://phab.mercurial-scm.org/D11089

dirstate-v2: Introduce a docket file .hg/dirstate now only contains some metadata to point to a separate data file named .hg/dirstate.{}.d with a random hexadecimal identifier. For now every update creates a new data file and removes the old one, but later we’ll (usually) append to an existing file. Separating into two files allows doing the "write to a temporary file then atomically rename into destination" dance with only a small docket file, without always rewriting a lot of data. Differential Revision: https://phab.mercurial-scm.org/D11088

dirstate: replace a dead conditional branch with an assert in `update_file` This is a case we never meet, so lets trim it away to simplify the code before more changes. Differential Revision: https://phab.mercurial-scm.org/D11128

dirstate-map: do not use `size` to gate copy dropping during remove_file This get us close to moving the block right above withing the DirstateItem object. Doing so will help us getting rid of magic constant at the dirstatemap level. Differential Revision: https://phab.mercurial-scm.org/D11127

dirstate: drop a duplicated assert This very case is checked in 3 line above that one. Differential Revision: https://phab.mercurial-scm.org/D11126

dirstate: drop duplicated check This is covered by the `@requires_parents_change` decorator that this function use. Differential Revision: https://phab.mercurial-scm.org/D11125

dirstate: add a `set_possibly_dirty` in `fakedirstatewritetime` Differential Revision: https://phab.mercurial-scm.org/D11122

dirstatemap: use `set_possibly_dirty` in `clearambiguoustimes` lets put this new method to use Differential Revision: https://phab.mercurial-scm.org/D11121

dirstate-item: use `set_possibly_dirty` in `pure.pack_dirstate` Lets make use of the new function. Differential Revision: https://phab.mercurial-scm.org/D11120

dirstate-item: add a `set_possibly_dirty` method See inline documentation for details. The pushes the AMBIGUOUS_TIME implementation further down the line within the DirstateItem only. When this cleanup is done we will be able to stop using this representation internally. Differential Revision: https://phab.mercurial-scm.org/D11119

dirstate-item: add a `from_v1_data` constructor This class method is dedicated to building a DirstateItem from the data available in the "dirstate-v1" format. Since that format is frozen, this constructor will never change (unlike the `__init__` one). Differential Revision: https://phab.mercurial-scm.org/D11118

dirstate-item: use an explicit __init__ function instead of the attrs one For now, this is not doing anything special, however we plan to make it different in the future. So we start simple. Differential Revision: https://phab.mercurial-scm.org/D11117

dirstate: deprecated `drop` outside of `update/merge` All core users have been migrated. Differential Revision: https://phab.mercurial-scm.org/D11116

dirstate: deprecated `remove` outside of `update/merge` All core users have been migrated. Differential Revision: https://phab.mercurial-scm.org/D11115

dirstate: deprecate the `add` method outside of update/merge context All core users have been updated. Differential Revision: https://phab.mercurial-scm.org/D11114

upgrade: avoid a traceback in case of unrecognized revlog Without this, in case of revlog name not matching any know pattern we would get a traceback. Raising a clear error seems simpler. Differential Revision: https://phab.mercurial-scm.org/D11202

walk: no longer ignore revlogs of files starting with `undo.` (issue6542) Changeset 0b569c75d180 introduced new code in store.walk to filter out undo files left behind by the transaction. However doing so is also filtering out legitimate revlog file starting with `undo.` So this changeset is mostly rolling back that change and adding tests tests to catch this kind of error in the future. As a result we the transaction undo files a considered again by various code (in practice mostly persistent nodemap related). We either live with it (low inconvenient) or explicitly work around it for now. This should be good enough to no longer block the 5.9rc release with this issue. We shall build something cleaner within the 6.0 cycle. Differential Revision: https://phab.mercurial-scm.org/D11201

largefiles: replace use of synclfdirstate with drop Replace calling a complex function with a simple dedicated one Differential Revision: https://phab.mercurial-scm.org/D11113

testing: do not stop waiting if timeout is 0 (issue6541) Differential Revision: https://phab.mercurial-scm.org/D11102

largefile: use `parentchange` markcommitted Differential Revision: https://phab.mercurial-scm.org/D11112

largefile: use `set_untracked` in the override of copy/rename This is the new shiny API Differential Revision: https://phab.mercurial-scm.org/D11111

largefile: use `set_untracked` in the `forget` override This is the new shinny API. Differential Revision: https://phab.mercurial-scm.org/D11110

largefile: directly use set_untracked() for removing files This is new shiny API. Differential Revision: https://phab.mercurial-scm.org/D11109

largefile: use `parentchange` during rollback rollback is updating parent without touching the working copy. It should wrapped in a `parentchange` context. Differential Revision: https://phab.mercurial-scm.org/D11108

largefile: consider `updatelfiles` as a `parentchange` This is not strictly a `parentchange`, however this is still some internal dirstate adjustment as "similar" enough that it seems find to do so. Differential Revision: https://phab.mercurial-scm.org/D11107

largefile: use `set_tracked` in the `hg copy` overwrite This is the new shiny API. Differential Revision: https://phab.mercurial-scm.org/D11106

largefile: use parentchange during mergerecordupdates This match what core is doing around recordupdates. Differential Revision: https://phab.mercurial-scm.org/D11105