verify: report censored nodes if configured policy is abort

context: handle censored data in an on-disk file context based on config Two possible behaviors are defined for handling censored data: abort, and ignore. When we ignore censored data we return an empty file to callers requesting the file data.

manifest: add fastdelta method to manifestdict This is another step closer to alternate manifest implementations that can offer different hashing algorithms.

manifest: move _search to module level and rename to _msearch The rename is intended to provide a slight hint that it is manifest-specific.

manifest: move manifestdict-to-text encoding to manifest class A future patch will introduce a new format, with a new class.

localrepo: access status fields by name rather than index

subrepo: use separate instances of empty lists in status We do modify the lists that make up the status in several places, so it seems risky to use the same instance of a list for several different status types. Use a separate empty list for each type instead.

summary: make status code more readable In commands.summary(), we currently zip a list of labels with a list of statuses. This means the order of the status list has to match the list of the labels, which in turn means the status elements have to be inserted into specific places in the list. Let's instead group the labels and status data we want to display in a single list of pairs.

strip: make checklocalchanges() return full status tuple By making checklocalchanges() return the full instance of the status class instead of just the first 4 elements of it, we can take advantage of the field names and not require the caller to remember the element indices.

fileset: access status fields by name rather than index

histedit: access status fields by name rather than index

shelve: access status fields by name rather than index

record: access status fields by name rather than index It is safe to pass the full status to patch.diff() since it does its own slicing.

purge: access status fields by name rather than index

largefiles: access status fields by name rather than index

keyword: access status fields by name rather than index

hgcia: access status fields by name rather than index

context: store status class instead of plain tuple in self._status This improves readability a bit by allowing us to refer to statuses by name rather than index.

status: update and move documentation of status types to status class The various status types are currently documented on the dirstate.status() method. Now that we have a class for the status types, it makese sense to document the status types there instead. Only leave the bits related to lookup/unsure in the status() method documentation.

status: update various other methods to return new class

status: create class for status lists Callers of various status() methods (on dirstate, context, repo) get a tuple of 7 elements, where each element is a list of files. This results in lots of uses of indexes where names would be much more readable. For example, "status.ignored" seems clearer than "status[4]" [1]. So, let's introduce a simple named tuple containing the 7 status fields: modified, added, removed, deleted, unknown, ignored, clean. This patch introduces the class and updates the status methods to return instances of it. Later patches will update the callers. [1] Did you even notice that it should have been "status[5]"? (tweaked by mpm to introduce the class in scmutil and only change one user)

lfutil: avoid creating unnecessary copy of status tuple In lfdirstatestatus(), the status tuple gets deconstructed, the lists get updated, and then an identical status tuple gets created and returned. Change it so we simply return the original tuple.

dirstate: separate 'lookup' status field from others The status tuple returned from dirstate.status() has an additional field compared to the other status tuples: lookup/unsure. This field is just an optimization and not something most callers care about (they want the resolved value of 'modified' or 'clean'). To prepare for a single future status type, let's separate out the 'lookup' field from the rest by having dirstate.status() return a pair: (lookup, status).

commit: update file nodeid and flags in the same place Now that we have a separate variable for the original 'm1' manifest, we can safely update the nodeid of the file in the new manifest in the same place as we update the flags.

commit: use separate variable for p1 manifest and new manifest In localrepo.commitctx(), p1's manifest is copied and used as the basis for the manifest that is about to be committed. The way the copy is updated makes it safe to use it where the original p1's manifest is wanted. For readability, though, a separate variable for each purpose would be clearer. Make it so.

commit: remove dead initialization of 'lock' The 'lock' variable is initialized to None, but before it's ever read, it's assigned again.

commit: reduce scope of 'removed' variable The variable is closely related to 'added' and 'changed', so it makes sense to have it declared next to them.

rebase: fix some weird mixed-case naming

rebase: move duplicatecopies next to merge This is preparation for removing open-coded rebase/graft operations. As a side-effect, this exposes proper renames in the working copy when there are conflicts, which shows up in test-shelve.t.

histedit: use merge.graft

graft: use merge.graft

merge: add merge.graft helper This will help unify all the open-coded graft/rebase operations.

duplicatecopies: move from cmdutil to copies This is in preparation for moving its primary caller into merge.py, which would be a layering violation in the current location.

histedit: fix indent The duplicatecopies call should be part of the rebase block.

graft: move rebase cleanup code next to actual rebase This is prep for refactoring the rebase logic.

shelve: add a bundlerepo method

dirstate: merge falls through to otherparent This lets us more correctly fix the state when we use setparents, as demonstrated in the change in test-graft.t.

dirstate: use 'm' state in otherparent to reduce ambiguity In rebase-like operations where we abandon the second parent, we can correctly fix up the state in setparents.

dirstate: properly clean-up some more merge state on setparents

phases: move root phase assignment to it's own function This moves the initial root phase assignment to it's own function. Future patches which make phase calculations lazy will use this function to pre-fill certain phases which can be deduced from the roots.

phases: add invalidate function Phase cache invalidation was spread all over the place. Let's add a function to unify it. Later more will be added to this function.

phases: change phase command change detection A future patch is going to make phase computation lazy, so the phase command can no longer read and diff the entire phase list directly. This changes the phase command to build it's own list for diff purposes.

spanset: remove `.set()` definition All my friends are dead.

generatorset: remove `.set()` definition All my friends are dead.

addset: remove `.set()` definition All my friends are dead.

filteredset: remove `.set()` definition All my friends are dead.

baseset: remove `set()` definition All my friends are dead.

abstractsmartset: remove `set()` method definition Now that all usages have been removed, we can drop this not so useful part of the API. We can note that the name was wrong all along...

match: check if an object is a baseset using `isascending` instead of `set` The `set()` method is going away.

getset: check if an object is a baseset using `isascending` instead of `set` The `set()` method is going away.

fullreposet: detect smartset using "isascending" instead of "set" The `.set()` function is going away.

fullreposet: drop custom sets but not smartsets detection All custom classes use by revsets are smartsets now. We drop the special-casing.

addset: drop `.set()` usage during iteration We can use the containment check directly.

baseset: access `_set` directly for containment check The `.set()` method is going away.

baseset: make `_set` a property cache This will remove the need for `baseset.set()`.

graphnode: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-_hexlist: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-_intlist: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-_list: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-roots: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

histedit: stabilise the order nodes that are stripped The `nodes` object is a set. We sort it to get stable order. This is going to prevent revsets from getting confused when removing a `.set()` call in `roots`.

revset-origin: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-last: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-limit: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-destination: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-children: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-branch: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-rangeset: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset-only: remove usage of `set()` All smartset classes have fast lookup, so this function will be removed soon.

revset: cache most conditions used in `filter` Except when stated otherwise, the condition used in `smartset.filter` will be cached. A new argument has been introduced to disable that behavior. We use it for filters created from `and` and `sub` operations. This gives massive performance boosts for revsets with expensive conditions. revset: branch(stable) or branch(default) before) wall 4.329070 comb 4.320000 user 4.310000 sys 0.010000 (best of 3) after) wall 2.356451 comb 2.360000 user 2.330000 sys 0.030000 (best of 4) revset: author(mpm) or author(lmoscovicz) before) wall 4.434719 comb 4.440000 user 4.440000 sys 0.000000 (best of 3) after) wall 2.321720 comb 2.320000 user 2.320000 sys 0.000000 (best of 4)

baseset: empty or one-element sets are ascending and descending The empty set is full of interesting properties. In the ordering case, the one element set is too.

filteredset: drop explicit order management Now that all low-level smartset classes have proper ordering and fast iteration management, we can just rely on the subset in filteredset.

revset: restore order of `or` operation as in Mercurial 2.9 Lazy revset broke the ordering of the `or` revset. We now stop assuming that two ascending revset are combine into an ascending one. Behavior in 3.0: 3:4 or 2:5 == [2, 3, 4, 5] Behavior in 2.9: 3:4 or 2:5 == [3, 4, 2, 5] We are adding a test for it. For unclear reason, the performance `or` revset with expensive filter are getting even worse than they used to be. This is probably caused by extra uncached containment check or iteration. revset #9: author(lmoscovicz) or author(mpm) before) wall 3.487583 comb 3.490000 user 3.490000 sys 0.000000 (best of 3) after) wall 4.481486 comb 4.480000 user 4.470000 sys 0.010000 (best of 3) revset #10: author(mpm) or author(lmoscovicz) before) wall 3.164839 comb 3.170000 user 3.160000 sys 0.010000 (best of 3) after) wall 4.574965 comb 4.570000 user 4.570000 sys 0.000000 (best of 3)

revset-_descendant: rework the whole sorting and combining logic We use the & operator to combine with subset (since this is more likely to be optimised than filter) and we enforce the sorting of the result. Without this enforced sorting, we may result in a different iteration order than the set _descendent was computed from. This reverts a bad `test-glog.t` change from 69402eb72115. Another side effect is that `test-mq.t` shows `qparent::` including `-1` if `qparent is -1`. This sound like a positive change. This has good and bad impacts on the benchmarks, here is a good ones: revset: 0:: before) wall 0.045489 comb 0.040000 user 0.040000 sys 0.000000 (best of 100) after) wall 0.034330 comb 0.030000 user 0.030000 sys 0.000000 (best of 100) revset: roots((0::) - (0::tip)) before) wall 0.134090 comb 0.140000 user 0.140000 sys 0.000000 (best of 63) after) wall 0.128346 comb 0.130000 user 0.130000 sys 0.000000 (best of 69) revset: ::p1(p1(tip)):: before) wall 0.143892 comb 0.140000 user 0.140000 sys 0.000000 (best of 55) after) wall 0.124502 comb 0.130000 user 0.130000 sys 0.000000 (best of 65) revset: roots((0:tip)::) before) wall 0.204966 comb 0.200000 user 0.200000 sys 0.000000 (best of 43) after) wall 0.184455 comb 0.180000 user 0.180000 sys 0.000000 (best of 47) Here is a bad one: revset: (20000::) - (20000) before) wall 0.009592 comb 0.010000 user 0.010000 sys 0.000000 (best of 222) after) wall 0.029837 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)

addset: do lazy sorting The previous implementation was consuming the whole revset when asked for any sort. The addset class is now doing lazy sorting like all other smarset classes. This has no significant impact in the benchmark as-is. But this is important to later change.

test-import.t: use proper revset order This test, written after 3.0, is relying on addset being enforced ascending if both side are ascending. We are about to restore the ordering to 2.9 behavior (elements are ordered in the order they are specified). We fix the test before fixing the order.

baseset: drop custom __sub__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant difference but real usecase may. This will also be important for further improvements to addset later in this series.

baseset: drop custom __and__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant regression but real usecase may. This even gives some speedup in some cases: revset #15: min(0::) before) wall 0.001247 comb 0.000000 user 0.000000 sys 0.000000 (best of 1814) after) wall 0.000942 comb 0.000000 user 0.000000 sys 0.000000 (best of 2367) This will also be important for further improvement to addset later in this series.

baseset: drop custom __add__ method This add method is enforcing non-laziness, disabling multiple optimisations. Benchmarks do not spot any significant differences but real usecase may. This will also be important for further improvements to addset later in this series.

obsolete: use format version 1 as the default for obsstore

test-obsolete: remove subminute timezone in test Obsmarker format "1" does not supports sub minute timezone. So we change the test to something slightly more sensible.

obsolete: add a "format.obsstore-version" config option This option controls what version of the binary format to use when creating a new obsstore file. Default is still the old format. No safeguards are currently placed around the option value, but no clueless users are in danger of harm since it is undocumented.

obsolete: introduce a new binary encoding for obsmarkers (version 1) This new encoding explicitly stores the date and parents allowing a significantly faster marker decoding. See inline documentation for details. This format is not yet used to store format on disk. But it will be used in bundle2 exchange if both side support it. Support for on-disk format is coming in other changesets.

obsstore: add a flag for sha256 hashes We add flag to inform that the marker is using sha256 hashes. As format 0 is not able to handle sha256 hashes (32 bytes long), we plain crash if we even attempt to encode a sha256 with it.

obsolete: use uint## in the format documention This is shorter and kind of more readable for people who care about binary format.

obsolete: gather _fm0 meta encoding with other _fm0 code

obsolete: _rename decodemeta to _fm0decodemeta This will be format zero specific.

obsolete: _rename encodemeta to _fm0encodemeta This will be format zero specific.

obsolete: store metadata as a tuple of (key, value) pairs (API) Different formats will encode metadata in different ways. So we cannot keep the binary blob in the object anymore. We use a tuple to ensure it is immutable and hashable.

merge with stable

templater: fix ifcontains when list is a string (issue4399)

shelve: don't delete "." when rebase is a no-op (issue4398) When unshelving and facing a conflict, if we resolve all conflicts in favour of the committed changes instead of the shelved changes, then the ensuing implicit rebase is a no-op. That is, there is nothing to rebase. In this case, there are no extra intermediate shelve commits to strip either. Prior to this change, the commit being unshelved to would be marked for destruction in a rather catastrophic way. The relevant part of the test case failed as follows: $ hg unshelve -c unshelve of 'default' complete $ hg diff warning: ignoring unknown working parent 33f7f61e6c5e! diff --git a/a/a b/a/a new file mode 100644 --- /dev/null b/a/a @@ -0,0 1,3 @@ a c x $ hg status warning: ignoring unknown working parent 33f7f61e6c5e! M a/a ? a/a.orig ? foo/foo $ hg summary warning: ignoring unknown working parent 33f7f61e6c5e! parent: -1:000000000000 (no revision checked out) branch: default commit: 1 modified, 2 unknown (new branch head) update: 4 new changesets (update) With this change, this test case now passes.

merge: make error message consistent with other commands If a merge is attempted when another merge is already ongoing, we give the message "outstanding uncommitted merges". Many other commands (such as backout, rebase, histedit) give the same message in singular form. Since the singular form also seems to make more sense, let's use that for 'hg merge' as well.

test-run-tests: add a test for detection of failure to start a server This also highlights a bug: right now we print "2 failed" but we only ran one test.

run-tests: more accurate/helpful message than "diff generation failed" Diff generation didn't really fail, it recognized that an hg serve server has failed to start, and thus skipped the diff generation intentionally. The most common reason for a server to fail to start is that the port was already in use, so output HGPORT as well, to help finding it (since pgrep -f 'hg serve' is not sufficient, if the command line is something like 'hg -R main serve')

run-tests: handle --jobs and --first gracefully Without this change, --first causes currently-running tests to explode in violent and surprising ways when their temporary directory gets cleaned up. Now we just suppress failure messages from non-first failures when running in --first mode.