- May 03, 2021
-
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10586
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10585
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10584
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10583
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10582
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10581
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10580
-
Pierre-Yves David authored
We currently using the "index file" to identify a revlog in error output. Since we are about to make the "index file" location more volatile, we need something better. We move to use the "radix", as it is close to what we currently use. We could probably do better, as pointed out in the comment, however that would be a quite detour from my current goal. Differential Revision: https://phab.mercurial-scm.org/D10579
-
Pierre-Yves David authored
We have a radix, lets use it! Differential Revision: https://phab.mercurial-scm.org/D10578
-
Pierre-Yves David authored
We now have the radix explicitely lets use the radix explicitely Differential Revision: https://phab.mercurial-scm.org/D10577
-
Pierre-Yves David authored
Instead of pointing to the index directly and to derive the other file from that, we directly provide the radix and let the revlog determine the associated file path internally. This is more robust and will give us more flexibility for picking this file name in the future. Differential Revision: https://phab.mercurial-scm.org/D10576
-
Pierre-Yves David authored
We want to make the actual location of the datafile and location more of an implementation details than what is is currently. In that process, we make the attribute private. Differential Revision: https://phab.mercurial-scm.org/D10575
-
Pierre-Yves David authored
We want to make the actual location of the indexfile and location more of an implementation details than what is is currently. In that process, we make the attribute private. Differential Revision: https://phab.mercurial-scm.org/D10574
-
Pierre-Yves David authored
Since `filelog` objects are not revlog (no really, they are not…) we drop the revlog specific attribute. We need to directly access the underlying revlog in a couple of place that already assume that we have a revlog here. This is motivated by future change to that revlog attribute. Differential Revision: https://phab.mercurial-scm.org/D10573
-
Pierre-Yves David authored
Since `manifestrevlog` object are not revlog (no really, they are not…) we drop the revlog specific attribute. We need to directly access the underlying revlog in a couple of place that already assume that we have a revlog here. This is motivated by future change to that revlog attribute. Differential Revision: https://phab.mercurial-scm.org/D10572
-
Pierre-Yves David authored
revlog usually use a straight forward '.i' and '.d' naming except for two cases "in-transaction" changelog, and censoring. Our goal is to let the revlog code deal with the internal of the file naming itself. To do so, we need to start dealing with these postfix explicitly. Differential Revision: https://phab.mercurial-scm.org/D10571
-
Pierre-Yves David authored
The part of the code is huge, keeping it separated will keep the `_loadindex` method simpler and help keeping logic well insulated. Differential Revision: https://phab.mercurial-scm.org/D10570
-
Pierre-Yves David authored
Same reasoning as the previous patch. Differential Revision: https://phab.mercurial-scm.org/D10569
-
Pierre-Yves David authored
It is simpler to manage the diferrence in on disk format in the internal index code itself and lets the rest of the code always handle the same object. This will become even more important when the data we store will be entirely different (for example the changelog does not need the "linkrev" field. We start with item reading, we will deal with item writing in the next changesets. Differential Revision: https://phab.mercurial-scm.org/D10568
-
Pierre-Yves David authored
This will allow for cleaner check than assuming each version has a different size. Unsurprisingly I am planning to use this to introduce more format variant. Differential Revision: https://phab.mercurial-scm.org/D10567
-
Pierre-Yves David authored
This is the size of and index entry, so lets make it clearer. Differential Revision: https://phab.mercurial-scm.org/D10566
-
Pierre-Yves David authored
The `revlog.version` attribute contained an integer coding 2 different informations: * the revlog version number * a bit field defining some specific feature of the revlog We now explicitly store the two components independently. This avoid exposing the implementation details all around the code and prepare for future revlog version that would encode the information in a different way. In the process we drop the `version` attribute from the interface. It was flagged for removal when that interface was created. Differential Revision: https://phab.mercurial-scm.org/D10565
-
Pierre-Yves David authored
Since `manifestrevlog` is not a `revlog`, we are passing strange thing to `_checkrevlog`. We fix this to avoid breakage during future change. Differential Revision: https://phab.mercurial-scm.org/D10564
-
Pierre-Yves David authored
Same logic as the previous changesets. Differential Revision: https://phab.mercurial-scm.org/D10563
-
Pierre-Yves David authored
This is more flexible and semantically more correct. The associated revlog's attribute exist since 827cb4fe62a3, so well we start linking sidedata to revlogv2. Differential Revision: https://phab.mercurial-scm.org/D10562
-
Pierre-Yves David authored
Most of this was already done when introducing the `target` parameter, but some remained. Having "indexfile" passed explicitely will help us to change the way we address a revlog later in the stack. With the introduction of more generic `docket`, the entry point will not necessarly be `xxx.i` file, and the actual index files will have a variable name. Differential Revision: https://phab.mercurial-scm.org/D10561
-
Pierre-Yves David authored
See comment for details. We will need to fix the test coverage when this incompatibility is lifted. Differential Revision: https://phab.mercurial-scm.org/D10544
-
Pierre-Yves David authored
The "w+" file mode is deleting all the content of the opened file. Which is bad… This is not caught by the test because the test only check for a full, initial pull where not pre-existing content exists. So we need to fix our test coverage here. However they are another issue that prevent "incremental" pull to work here. See next changeset for details. Differential Revision: https://phab.mercurial-scm.org/D10543
-
- May 07, 2021
-
-
Simon Sapin authored
* Size-preserving file contents modification * Filtering output to a deleted or removed file Differential Revision: https://phab.mercurial-scm.org/D10701
-
Simon Sapin authored
With `hg status -X`, not just include pattern with `hg status -I` Differential Revision: https://phab.mercurial-scm.org/D10700
-
Simon Sapin authored
… when using the new status algorithm and the tree-based dirstate. The previous algorithm still has this bug. Differential Revision: https://phab.mercurial-scm.org/D10699
-
- May 03, 2021
-
-
Simon Sapin authored
The `dirstate-v1` variant has the previous behavior. `dirstate-v1-tree` uses the same format on disk, but uses the new `DirstateMap` with a tree data structure and the new `status` algorithm. These were untested so far. Differential Revision: https://phab.mercurial-scm.org/D10698
-
- May 08, 2021
-
-
Matt Harbison authored
-
- May 07, 2021
-
-
Martin von Zweigbergk authored
It's quite common that users want to record copy (rename) information after committing the working copy changes (i.e. an added and a deleted file). When they try `hg mv [--after] <src> <dst>`, that just fails because the source file doesn't exist. It seems helpful if we can point them to `--at-rev=.` in this case. Differential Revision: https://phab.mercurial-scm.org/D10697
-
- Apr 30, 2021
-
-
Simon Sapin authored
Use std::borrow::Cow to avoid some memory allocations and copying. Differential Revision: https://phab.mercurial-scm.org/D10560
-
Simon Sapin authored
Use std::borrow::Cow to avoid some memory allocations and copying. These particular allocations are not visible when profiling (as many files in a typical repo don’t have a copy source). This change is "warm up" for doing the same with paths of files themselves, which is more involved since those paths are used as `HashMap` keys. This gets of the way the addition of a lifetime parameter to several types. Differential Revision: https://phab.mercurial-scm.org/D10559
-
Simon Sapin authored
Getting the former (through `Deref`) is almost the only useful thing one can do with the latter anyway. With this changes, API become more flexible for the "provider" of these paths which may store something else that Deref’s to HgPath, such as `std::borrow::Cow<HgPath>`. Using `Cow` can help reduce memory alloactions and copying. Differential Revision: https://phab.mercurial-scm.org/D10558
-
Simon Sapin authored
… that has the contents of the `.hg/dirstate` file. This only applies to the tree-based flavor of `DirstateMap`. For now only the entire `&[u8]` slice is stored, so this is not useful yet. Adding a lifetime parameter to the `DirstateMap` struct (in hg-core) makes Python bindings non-trivial because we keep that struct in a Python object that has a dynamic lifetime tied to Python’s reference-counting and GC. As long as we keep the `PyBytes` that owns the borrowed bytes buffer next to the borrowing struct, the buffer will live long enough for the borrows to stay valid. However this relationship cannot be expressed in safe Rust code in a way that would statisfy they borrow-checker. We use `unsafe` code to erase that lifetime parameter, and encapsulate it in a safe abstraction similar to the owning-ref crate: https://docs.rs/owning_ref/ Differential Revision: https://phab.mercurial-scm.org/D10557
-
Simon Sapin authored
Before this changeset, Python code first creates an empty `DirstateMap` Rust object, then immediately calls its `read` method with a byte string of the contents of the `.hg/dirstate` file. This makes that byte string available to the constructor of `DirstateMap` in the hg-cpython crate. This is a first step towards enabling parts of `DirstateMap` in the hg-core crate to borrow from this buffer without copying. Differential Revision: https://phab.mercurial-scm.org/D10556
-
Simon Sapin authored
The Python wrapper class `dirstatemap` can take care of it. This removes the need to have both `_rustmap` and `_inner_rustmap`. Differential Revision: https://phab.mercurial-scm.org/D10555
-