Summary:
I noticed this takes 500+ms in some cases. Let's track both the old
computation and the new, and flag them so we can differentiate between them.
Differential Revision: D15156559
fbshipit-source-id: ec2983081e4fa01d017212783e3fcb040f9fd4e5
Summary:
When detecting split completion for the purposes of recording mutation, we used
`cmdutil.comparechunks`. This doesn't work for curses-recordings where the
only change is that some lines of a patch were excluded.
A simpler check is to just generate the patch that split is going to use, and
see if that matches the original patch.
Additionally, prevent the insertion of empty split records, as this can
cause crashes.
Reviewed By: mitrandir77
Differential Revision: D15063983
fbshipit-source-id: ba717d7f065faea93a500caaf10a1dbf582c7ab1
Summary:
Ordinarily loops are prevented in the mutation graph as the predecessors must exist
at the point that the successor is created. However, backfilling from a complex
obsolescence graph may inadvertently introduce cycles.
Since loops are invalid, we can safely ignore any mutation edges that may
introduce them. The `allpredecessors` and `allsuccessors` functions already
do this.
Add loop detection and ignoring to the `predecessorsset` and `successorssets`
functions.
Reviewed By: mitrandir77
Differential Revision: D15062399
fbshipit-source-id: fe892d9236c8d8dc4e1322b82618ab4bca35d30a
Summary:
When computing the fate of a commit, if we find the immediate successor is the
next visible commit, we return the operation of the mutation record for that
single operation. If it's not available, we then look at whether or not the
commit is public to decide between the fallbacks of `land` or `rewrite`.
Unfortunately, not all land operations end up with a `land` op. In particular,
obsmarkers created with pullcreatemarkers and then backfilled into mutation
records have a blank operation, and so we show `rewrite` here when we should
show `land`.
Switch around how we calculate the fate. Compute a default operation of `rewrite`
or `land`, based on the phase of the successor, and then use that if the successor
is not the immediate successor, or if the recorded operation is blank.
Reviewed By: mitrandir77
Differential Revision: D15061863
fbshipit-source-id: 753b0b58f84e653b40f9918f7ad3b3adfff359d8
Summary:
In the automigrate step at the start of pull, perform automigrations for
mutation and visibility.
If `mutation.automigrate` is set to true, then backfill obsmarkers into the
mutation store. This step can take a couple of seconds for large obsstores, so
print a message.
If `visibility.automigrate` is set to `"start"`, switch to explicit visibility
tracking. If it is set to `"stop"`, switch back to obsmarker-based tracking.
Reviewed By: mitrandir77
Differential Revision: D15046139
fbshipit-source-id: 284268d42b52c6b296c5c1b73db7bc218ae29a0a
Summary:
The computation of whether a commit is obsolete or not can be improved.
We can cache which commits are known to not be obsolete.
We can also have a cache for each filter type so that we only need to compute
obsolete nodes that match the filter.
Finally, when we need to compute all obsolete commits, we can start by looking
for commits which are made obsolete by only their closest successors, and then
filling back obsolescence to the predecessors of these obsolete commits.
Reviewed By: DurhamG
Differential Revision: D14858655
fbshipit-source-id: 1d03e214ad878ecb6ae548f80373702e2a184146
Summary:
When changes are undone so that an earlier view of the repo is present, fate
should only be calculated for commits that are obsolete in the current view.
This makes smartlog look correct after `undo` commands have been used.
Reviewed By: quark-zju
Differential Revision: D14603198
fbshipit-source-id: 3adaad94b9fe80e8a622d469513c784b772ee235
Summary:
Record mutation entries inside transactions. This ensures that they only get
written when the transaction completes.
Indexedlog doesn't have support for pending writes, so mutation entries are not
visible to hook scripts.
Reviewed By: quark-zju
Differential Revision: D14566781
fbshipit-source-id: eb4c7bbd3878df82e8e7096a69509525f9fb93c0
Summary:
Remove the last parts of the mutationcache, relying directly on the indexedlog
indexes.
The set of obsolete commits is now computed on the fly - we will cache this
later.
Reviewed By: quark-zju
Differential Revision: D14566780
fbshipit-source-id: 770d0d9d507bed982e88518dcf63a4c2d6b46a69
Summary:
To prepare for transaction support, we need to move the store out of the cache
object and into its own property on the localrepo.
Reviewed By: quark-zju
Differential Revision: D14566776
fbshipit-source-id: 8fff03a86953fb60ed06dbbdcdd0bffc379bd047
Summary:
Computing mutation entries for all local commits is expensive when there are
lots of local draft commits. Ideally we would have an indexed changelog that
would make these lookups fast, but until we have that, put entries in the
mutation store for these commits to take advantage of the fast lookup there.
Reviewed By: quark-zju
Differential Revision: D14566782
fbshipit-source-id: cc3a05715337a510a65d8ff436c59d16d0f0447e
Summary:
The computations for instabilities revsets (`orphan`, `contentdivergent` and
`phasedivergent`) are complex, and aren't really necessary for the way we use
mutation information.
The `orphan` revset can be implemented as an alias for `obsolete():: -
obsolete()`. The other conditions can be detected on a case-by-case basis
later if we need them.
Reviewed By: quark-zju
Differential Revision: D14566784
fbshipit-source-id: 60b8443ad4c0c82d8250d8e9a10e73fae770daa8
Summary:
To support future alternate hashing schemes, predecessor identities should be
prefixed with the hashing scheme in use.
Currently there is only one hashing scheme: `hg`, which is the Mercurial
hashing scheme.
Reviewed By: quark-zju
Differential Revision: D14566778
fbshipit-source-id: baaaf2f078886a1cc7ac20d12923a63b4da09db6
Summary:
Add support for detecting landed commits.
Since we don't currently have an index for successor information in the
changelog, we can only detect the successor relationship for predecessors of
draft commits (for which we build a cache). As a temporary workaround,
make it possible to put mutation records in the mutation store that lead to
landed commits. These will allow land detection to work until we have a
changelog that supports indexing on predecessor.
Reviewed By: quark-zju
Differential Revision: D12980780
fbshipit-source-id: d7b14fa073d0406990b92731fe66dfe1c73b404c
Summary:
The `mutations` template keyword expands to a list of the results of mutating
the commit. Each element of the list has an `operation` field, which is a
string describing the mutation operation, and a `successors` field, which is a
list of the successor commits for this operation. Sequences of mutations that
result in a single successor are collapsed into a single `rewrite` operation.
Reviewed By: quark-zju
Differential Revision: D12980787
fbshipit-source-id: 82be2f9131832209cc3ab088f587c45f8c45a9ad
Summary:
Include mutation records for all predecessors of the pushed commits in
infinitepush bundles.
When received from infinitepush, store these additional records in the local
store. This allows us to bridge any gaps in mutation that are omitted from the
local commits when they are received from infinitepush.
Reviewed By: DurhamG, quark-zju
Differential Revision: D12980777
fbshipit-source-id: b1535ca29c0fca3e6cb0f563d78c4c60d4aef58e
Summary:
The debugmutation command should also show information about mutation entries
in the mutation store.
Reviewed By: DurhamG, quark-zju
Differential Revision: D12980785
fbshipit-source-id: 06c3ec2cb9c42edf43729ba3b7c471b1bf8dfb96
Summary:
When traversing mutation entries, if we don't have any information for a
commit, then look instead in the store to see if we have a cached entry
from a non-local commit there.
There aren't any ways of putting entries there, yet. Those will come in
later commits.
Reviewed By: DurhamG
Differential Revision: D12980776
fbshipit-source-id: 63ff12382eb9294aa43ff100a4fe19b7c05f9e61
Summary:
We will be making looking up entries for complex by adding a secondary store of
the information. Make accesses to this information common through lookup
functions.
Reviewed By: quark-zju
Differential Revision: D13279986
fbshipit-source-id: a30084b548762e69cb354c3760d7ec66027a24e1
Summary:
Implement successorssets and foreground in terms of mutation records and
replace them when mutation metadata usage is enabled.
Reviewed By: quark-zju
Differential Revision: D10149263
fbshipit-source-id: bbf6d1fc44a9787660147e15936a9ee1951373ca
Summary:
When enabled, use mutation metadata for the `obsolete`, `extinct`, `orphan`,
`phasedivergent` and `contentdivergent` revsets.
Reviewed By: quark-zju
Differential Revision: D10149265
fbshipit-source-id: 5559fa22a6025e1d341538f3eb2257d8efee15e5
Summary:
Add a mutationcache to the repo. This computes the following information:
* The successor sets for all predecessors of visible commits - these are the
sets of immediate successors for each commit.
* A map from commits which are the results of splits to the final split commit.
* The set of public commits that have visible draft successors.
* The set of draft commits that have multiple sets of visible eventual successors.
* The set of obsolete commits - draft commits with visible eventual successors.
* The set of orphan commits - commits with obsolete ancestors.
* The set of extinct commits - obsolete commits with no orphaned descendants.
These sets will be used later on to replace the obsmarker-based equivalents.
Reviewed By: DurhamG
Differential Revision: D13279988
fbshipit-source-id: 3f063bb68aaba2f19da257efdf79b485b947b7b1
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.
Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.
Reviewed By: phillco
Differential Revision: D13868981
fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
Summary:
Move top-level Python packages `mercurial`, `hgext` and `hgdemandimport` to
a new top-level package `edenscm`. This allows the Python packages provided by
the upstream Mercurial to be installed side-by-side.
To maintain compatibility, `edenscm/` gets added to `sys.path` in
`mercurial/__init__.py`.
Reviewed By: phillco, ikostia
Differential Revision: D13853115
fbshipit-source-id: b296b0673dc54c61ef6a591ebc687057ff53b22e
