The fsmonitor extension should send state-enter and state-leave
notifications to watchman when the wlock is acquired/release, respectively.
This will allow watchman and watchman subscribers to customize behavior based
on whether source control operations are occurring.
Test Plan:
Tested checkout, update and working copy changes with extension enabled.
Differential Revision: https://phab.mercurial-scm.org/D1612
Remove working copy change and transaction notifications. We were relying
upon callbacks on transaction function. This caused issues with lock ordering.
A different approach will be adopted in a subsequent commit.
Differential Revision: https://phab.mercurial-scm.org/D1611
Change the C implementation of phasecache.loadphaserevs to provide only
the sets for draft and secret phase as well as the number of revisions
seen.
Change the pure Python implementation of the same functino to compute
the sets instead of the list of phases for each revision.
Change phasecache.phase to check the phase sets and assume public if the
revision is in neither draft nor secret set. This is computationally
slightly more expensive.
Change phasecache.getrevset for public() based queries to compute the
set of non-matching revisions and return the result as filtered
fullreposet. A shortcut is taken when no draft or secret revision
exists.
Bump the module version for the changed interface contract.
Overall, this saves around 16 Bytes per revision whenever the phasecache
is used, for the test case in issue5691 it is around 3MB. getrevset()
for a large repository is around 13% slower here, that seems an
acceptable trade off. Performance impact for phase() should be similar.
Differential Revision: https://phab.mercurial-scm.org/D1606
Revisions are added consecutively, so a range can easily represent them
in the changes list. This saves around 45 Bytes / revision on 64bit
platforms and reduces the memory footprint of issue5691 by 15MB.
Don't copy changes['revs'] in getobsoleted. Ranges have a very efficient
contains implementation already.
Differential Revision: https://phab.mercurial-scm.org/D1615
This is a little risky, as I think we can have some encoding weirdness
crop up. showfunc also isn't the most robust feature, but it's still
often useful context...
Differential Revision: https://phab.mercurial-scm.org/D1610
This was part of the original proposal, and while *I* don't like the
curses interface, most users anecdotally seem to greatly prefer it to
plain text interfaces.
Differential Revision: https://phab.mercurial-scm.org/D1609
This changeset make use of the ability of the set discovery to only search
common changeset for a subset of the repository. Restricting that search to the
pushed set avoid potential waste of time finding out the status of many
unrelated related revision.
Repository with many heads were especially badly affected by this. Here is an
example of findcommonhead discovery for pushing 11 outgoing changeset on a
repository with tens of thousand of unrelated heads. (discovery run over a ssh
link to localhost).
Before:
queries: 92
time: 44.1996s
After:
queries: 3
time: 0.6938s
A x63 speedup even with a network link without latency.
Currently, the push discovery first determines the full set of common nodes
before looking into what changesets are outgoing. When pushing a specific
subset, this can lead to pathological situations where we search for the status
of thousand of local heads that are unrelated to the requested pushes.
To fix this, we need to teach the discovery to ignores part of the graph. Most
of the necessary pieces were already in place. This changeset just makes them
available to higher level API and tests them.
Change actually impacting pushes are coming in a later changeset.
The extensions wrap the necessary function to ensure the 'largefiles'
requirements won't be dropped.
It is now possible to run `hg debugupgraderepo` on a repository with largefiles.
Some requirement does not directly result from config and needs more advanced
logic to be preserved. The current example is 'largefiles'. We add a hook
point in the upgrade code so that extensions can handle these cases.
The 'largefiles' extension will use it in the next changeset.
The original filectx API is kept public since we'll need it to walk ancestor
(rev, match) pairs efficiently. The current implementation scans ancestors
twice for 'hg log -fp FILE'.
This is in preparation to switch this class to inheriting (and being based off
a) `commitctx` instead of a `workingctx`. `filectx` has no `exists` function,
so this is how we'll fall back in that case.
Differential Revision: https://phab.mercurial-scm.org/D1237
In the future, the --inmemory flag might be deprecated in favor of something more
intelligent (for example, always rebasing in-memory if the working copy parent
isn't in the rebaseset). But we might keep it as a way to explicitly force IMM
on or off.
Differential Revision: https://phab.mercurial-scm.org/D1232
With rebase, we will be setting the _wrappedctx at a different point from the
wctx construction (somewhat later, and possibly several times). Move it to a
public function.
Differential Revision: https://phab.mercurial-scm.org/D1231
This was intended to be done by D470. But there was a minor documentation
issue. The feature is quite usable now so it gets formally documented and
enabled.
There is no behavior change for people not using the `SRC` or `ALLSRC` in
rebase destination revset.
.. feature:: Rebase with different destination per source revision
Previously, rebase only supports one unique destination. Now ``SRC`` and
``ALLSRC`` can be used in rebase destination revset to precisely define
destination per each individual source revision.
For example, the following command could move some orphaned changesets to
reasonable new places so they become no longer orphaned::
hg rebase
-r 'orphan()-obsolete()'
-d 'max((successors(max(roots(ALLSRC) & ::SRC)^)-obsolete())::)'
Differential Revision: https://phab.mercurial-scm.org/D1063
Merge conflicts might be supported in the future, but for now are kept out of
scope.
Any places where we used to call `flushall()` should be replaced with some kind
of exception. At this point, IMM M1 is no longer supported.
Differential Revision: https://phab.mercurial-scm.org/D1212
I added `ctx()` to `overlayworkingfilectx`, (and before that, `absentfilectx`),
because `absentfilectx` had reference to this function in its `cmp()` function.
But the standard is actually `changectx()`, and no other class implements
`ctx()`. So let's use the standard name.
(As a result, I'm not sure that part of the `absentfilectx` comparator ever
worked! It was written before I added either function.)
This will be necessary in the next patch.
Differential Revision: https://phab.mercurial-scm.org/D1211
This is the same mechanism in place for largefiles, and solves several problems
working with multiple local repositories. The existing largefiles method is
reused in place, because I suspect that there are other functions that can be
shared. If we wait a bit to identify more before `hg cp lfutil.py ...`, the
history will be easier to trace.
The push between repo14 and repo15 in test-lfs.t arguably shouldn't be uploading
any files with a local push. Maybe we can revisit that when `hg push` without
'lfs.url' can upload files to the push destination. Then it would be consistent
for blobs in a local push to be linked to the local destination's cache.
The cache property is added to run-tests.py, the same as the largefiles
property, so that test generated files don't pollute the real location. Having
files available locally broke a couple existing lfs-test-server tests, so the
cache is cleared in a few places to force file download.
Largefiles puts everything into a flat directory, while lfs divides files up by
creating subdirectories consisting of the first two characters of the hash.
Therefore, pointing at the largefiles cache won't work.
The `diff' command usually writes deletion in red and insertions in green. This
patch adds within-line colors, to highlight which part of the lines differ.
Lines to compare are decided based on their similarity ratio, as computed by
difflib SequenceMatcher, with an arbitrary threshold (0.7) to decide at which
point two lines are considered entirely different (therefore no inline-diff
required).
The current implementation is kept behind an experimental flag in order to test
the effect on performance. In order to activate it, set inline-color-diff to
true in [experimental].
We can't use fctx.linkrev() to sort fctxs coming from multiple files.
This was changed at a5b8b1052ef6 due to performance issue, but we know
we evaluate parent.rev() in revset anyway.
The primary goal of this series is to make follow() support multiple start
revisions.
dagop.filectxancestors() will be extended to take multiple filectxs.
basefilectx.ancestors() is not forwarded to this function because doing that
would resurrect the performance issue fixed by a5b8b1052ef6.
This covers a possible bug that could be caused by the following change:
--- a/mercurial/context.py
+++ b/mercurial/context.py
@@ -1047,7 +1047,7 @@ class basefilectx(object):
while True:
for parent in c.parents()[:cut]:
- visit[(parent.linkrev(), parent.filenode())] = parent
+ visit[parent.linkrev()] = parent
if not visit:
break
c = visit.pop(max(visit))
This makes pull consistent with the part used by push and provide us with a
more compact representation of bookmarks.
In addition, this opens the way for smarter bookmark exchanges (e.g. filtering
by names or only sending the bookmark relevant to the pulled set, etc).
In this mode, the bookmarks changes are record in the 'bundleoperation' records
instead of inflicted to the repository. This is necessary to use the part when
pulling.
This new attribute allows the codes requesting an unbundling to pass important
information to individual part handlers. The current target use case is to
allow for receiving 'bookmarks' part without directly updating local
repository, but just recording the received data instead. This is necessary
for pull where the remote bookmarks are processed locally. I expect the
concept to be beneficial to other parts in the future.
To clarify the bookmark behavior on pull, the remote bookmark value are not just
taken -as-is- into the local repository. There is an extra step to detect
bookmark divergence. The remote bookmarks data are stored until this processing
happens.
We use the new binary parts we introduced earlier to exchange bookmark. The
payload is a bit more compact since we use binary and the length of bookmarks
is no longer constrained to 255.
.. fix:: Issue 5165
Bookmark, whose name is longer than 255, can again be exchanged again
between 4.4+ client and servers.
