Instead of wrapping committablectx.markcommitted(), we inline
the call into workingctx.markcommitted().
Per smf's review, workingctx is the proper location for this
code, as committablectx is the shared base class for it and
memctx. Since this code touches the working directory, it belongs
in workingctx.
Previously, histedit.cleanupnode pass root nodes one by one. Since
repair.strip takes multiple nodes and can handle them just fine, pass all
strip roots at once.
This is BC because the number of strip backup files may change from N to 1.
histedit treats topmost bookmark movement specially. The rest of the
bookmark movement could be handled by scmutil.cleanupnodes. So let's move
the special logic out to make the patch easier to review.
This is more consistent with other commands, like "commit -v" won't show
bookmark movement messages.
It will make migrating to scmutil.cleanupnodes easier.
This patch migrates rebase to use scmutil.cleanupnodes API. It simplifies
the code and makes rebase code reusable inside a transaction.
This is a BC because the backup file is no longer strip-backup/*-backup.hg,
but strip-backup/*-rebase.hg. The latter looks more reasonable since the
directory name is "strip-backup" so there is no need to repeat "backup".
I think the backup file name change is probably fine as a BC, since we have
changed it before (2e51c9a7a08f) and didn't get complains. The end result
of this series will be a much more consistent and unified backup names:
command | old backup file suffix | new backup file suffix
-------------------------------------------------------------------
amend | amend-backup.hg | amend.hg
histedit | backup.hg (could be 2 files) | histedit.hg (single file)
rebase | backup.hg | rebase.hg
strip | backup.hg | backup.hg
(note: backup files are under .hg/strip-backup)
It also fixes issue5606 as a side effect because the new "delayedstrip" code
path will carefully examine nodes (safestriproots) to make sure orphaned
changesets won't get stripped by accident.
Some warning messages are changed to the new "warning: orphaned descendants
detected, not stripping HASHES", which provides more information about
exactly what changesets are left behind.
Another minor behavior change is when there is an obsoleted changeset with a
successor in the destination branch, bookmarks pointing to that obsoleted
changeset will not be moved. I have commented in test-rebase-obsolete.t
explaining why that is more desirable.
This is a pretty straightforward move of the code.
I converted the "force" argument to a keyword argument.
Like other recent changes, this code is tightly coupled with
working directory update code in merge.py. I suspect the code
will become more tightly coupled over time, possibly even moved
to merge.py. For now, let's get the code in core.
merge.calculateupdates() now filters the update actions through sparse
by default.
The filtering no-ops if sparse isn't enabled or no sparse config
is defined.
The function has been refactored to behave more like a filter
instead of a wrapper of merge.calculateupdates().
We should arguably take sparse into account earlier in
merge.calculateupdates(). This patch preserves the old behavior
of applying sparse at the end of update calculation, which is the
simplest and safest approach.
This was our last method on the custom repo type, meaning we could
remove that custom type and inline the 2 lines of code into
reposetup().
As part of the move, instead of wrapping merge.update() from
the sparse extension, we inline the function call. The ported
function now no-ops if sparse isn't enabled, making it safe to
always call.
The call site in update() may not be the most appropriate. But
it matches the previous behavior, which is the safest thing
to do. It can be improved later.
As part of the move, the function arguments changed so revs are
passed as a list instead of *args. This allows us to use keyword
arguments properly.
Since the plan is to integrate sparse into core and have it
enabled by default, we need to prepare for a sparse matcher
to always be obtained and operated on. As part of the move,
we inserted code that returns an always matcher if sparse
isn't enabled. Some callers in the sparse extension take this
into account and conditionally perform matching depending on
whether the special always matcher is seen. I /think/ this
may have sped up some operations where the extension is
installed but no sparse config is activated.
One thing I'm ensure of in this code is whether os.path.dirname()
is semantically correct. os.posixpath.dirname() (which is
exported as pathutil.dirname) might be a better choise because
all patterns should be using posix directory separators (/)
instead of Windows (\). There's an inline comment that implies
Windows was tested. So hopefully it won't be a problem. We
can improve this in a follow-up. I've added a TODO to track it.
The sparse extension contains some matcher types that are
generic and can exist in core.
As part of the move, the classes now inherit from basematcher.
always(), files(), and isexact() have been dropped because
they match the default implementations in basematcher.
sparse.py in FB's hg-experimental repo switched to using __repr__ for
non-sparse matchers soon after hg core started overriding __repr__ in
the matchers in match.py (because the core matchers also stopped
having "includepat" and other attributes that sparse used to depend
on). Let's finish that migration by implementing __repr__ in the
sparse matchers as well. That also lets us remove the special handling
of them in _hashmatcher().
Largefiles isn't a good candidate for in-memory merge (it uses a custom
dirstate, matcher, and the files might not fit in memory) so have it always
run an old-style merge.
Differential Revision: https://phab.mercurial-scm.org/D683
Previously, blackbox always appends to blackbox.log and creates the
directory for that file on demand. That could be an issue if:
1. chg starts from `$REPO` directory, so `ui._bbrepo` is set.
2. `rm -rf $REPO`.
3. `chg init $REPO`, blackbox writes something and `init` will fail
because `$REPO` directory is non-empty.
This patch fixes that by verifying whether vfs exists before re-using it.
Differential Revision: https://phab.mercurial-scm.org/D768
This makes use of the generic method of listing bookmarks and tags, so
other extensions that add other namespaces will get their names added
too.
This does mean that bookmarks will come before tags, just like we
apparently decided to order them in the "hg log" output. It doesn't
seem like people would be parsing the rebase output anyway. We also
did 9461eb4ff93e (rebase: use _ctxdesc in one more place, 2017-08-29)
recently, so now seems like a good time.
Differential Revision: https://phab.mercurial-scm.org/D741
There are people who wants to do `hg uncommit` on dirty working directory, so
this patch adds a config which can be used to the achieve that.
Adds tests for the same.
Differential Revision: https://phab.mercurial-scm.org/D735
As per IRC discussion and suggestion by Augie, we should not allow bare `hg
uncommit` on dirty working directory.
Differential Revision: https://phab.mercurial-scm.org/D734
This patch renames the flag 'empty' which retains the empty changeset if all
the files are uncommitted to 'keep'.
Differential Revision: https://phab.mercurial-scm.org/D726
`lastui` decides where (where is the `.hg`) to use if the current `ui`
object does not have a `_bbrepo` associated. Previously it only gets set in
`ui.log`, which means unless a `ui` with repo associated calls `log` with
tracked event, blackbox does not know where to write its log. This patch
makes `reposetup` set `lastui` so it so we could log some more events (see
test changes).
Differential Revision: https://phab.mercurial-scm.org/D655
It seems cleaner to just remove `_partialinit`, `copy`, `__init__`. This
patch makes it so by using `getattr` in `log` so those fields do not need to
be existed.
Differential Revision: https://phab.mercurial-scm.org/D652
uncommit extension in fb-hgext adds a uncommit command which by default
uncommits a changeset and move all the changes to the working directory. If
file names are passed, uncommit moves the changes from those files to the
working directory and left the changeset with remaining committed files.
The uncommit extension in fb-hgext does not creates an empty commit like the one
in evolve extension unless user has specified ui.alllowemptycommit to True.
The test file added is a combination of tests from test-uncommit.t,
test-uncommit-merge.t and test-uncommit-bookmark.t from fb-hgext.
.. feature::
A new uncommit extension which provides `hg uncommit` using which one can
uncommit part or all of the changeset. This command undoes the effect of a
local commit, returning the affected files to their uncommitted state.
Differential Revision: https://phab.mercurial-scm.org/D529
`hg show` makes heavy use of shortest() to limit the length of the node
hash.
For the "stack" and "work" views, you are often looking at multiple
lines of similar output for "lines" of work. It is visually appeasing
for things to vertically align. A naive use of {shortest(node, N)}
could result in variable length nodes and for the first character of
the description to vary by a column or two.
We implement a function to determine the longest shortest prefix for
a set of revisions. The new function is used to determine the printed
node length for all `hg show` views.
.. feature::
show: use consistent node length in views
Our previous shortest node length of 5 was arbitrarily chosen.
shortest() already does the work of ensuring that a partial node
isn't ambiguous with an integer revision, which is our primary risk
of a collision for very short nodes. It should be safe to go with the
shortest node possible.
Existing code is also optimized to handle nodes as short as 4.
So, we decrease the minimum hash length from 5 to 4.
We also add a test demonstrating that prefix collisions increase the
node length.
.. feature::
show: decrease minimum displayed hash length from 5 to 4
Differential Revision: https://phab.mercurial-scm.org/D558
In the in-memory merge branch. we'll need to call a function (``flushall``) on
the wctx inside of _xmerge.
This prepares the way so it can be done without hacks like ``fcd.ctx()``.
Differential Revision: https://phab.mercurial-scm.org/D449
Having the blackbox file objects cached in `ui._bbfp` could in theory be
troublesome if multiple processes (ex. chg servers) have file objects
referring to a same file. (Although I spent some time and failed to build a
convincing test case)
This patch makes blackbox re-open the file every time to make the situation
better. Ideally we also need proper locking.
The caching logic traces back to the commit introducing blackbox
(18242716a). That commit does not have details about why caching is
necessary. Consider the fact that blackbox logs are not many, it seems fine
to remove the fp cache to be more confident.
Differential Revision: https://phab.mercurial-scm.org/D650
The added test will show:
$ $PYTHON showsize.py .hg/blackbox*
.hg/blackbox.log: < 500
.hg/blackbox.log.1: < 500
.hg/blackbox.log.2: < 500
.hg/blackbox.log.3: < 500
.hg/blackbox.log.4: < 500
.hg/blackbox.log.5: >= 500
with previous code.
The issue is caused by blackbox caching file objects *by path*, and the
rotation size check could run on a wrong file object (i.e. it should check
"blackbox.log", but `filehandles["blackbox.log"]` contains a file object
that has been renamed to "blackbox.log.5").
This patch removes the "filehandlers" global cache added by 39bd7b0c79fe to
solve the issue.
I think the original patch was trying to make different ui objects use a same
file object if their blackbox.log path is the same. In theory it could also
be problematic in the rotation case. Anyway, that should become unnecessary
after D650.
Differential Revision: https://phab.mercurial-scm.org/D648
As part of getting rid of all the permutations of changegroup creation, let's
remove changegroupsubset and call makechangegroup instead. This moves the
responsibility of creating the outgoing set to the caller, but that seems like a
relatively reasonable unit of functionality for the caller to have to care about
(i.e. what commits should be bundled).
Differential Revision: https://phab.mercurial-scm.org/D665
Now we have a clear centric place to control whether `rbsrt.repo` is
unfiltered or not, we can drop `unfiltered()` in other places.
Differential Revision: https://phab.mercurial-scm.org/D645
This is similar to Martin von Zweigbergk's previous patch [1].
Previous patches are adding more `.unfiltered()` to the rebase code. So I
wonder: are we playing whack-a-mole regarding on `unfiltered()` in rebase?
Thinking about it, I believe most of the rebase code *should* just use an
unfiltered repo. The only exception is before we figuring out a
`rebasestate`. This patch makes it so. See added comment in code for why
that's more reasonable.
This would make the code base cleaner (not mangling the `repo` object),
faster (no need to invalidate caches), simpler (less LOC), less error-prone
(no need to think about what to unhide, ex. should we unhide wdir p2? how
about destinations?), and future proof (other code may change visibility in
an unexpected way, ex. directaccess may make the destination only visible
when it's in "--dest" revset tree).
[1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/094277.html
Differential Revision: https://phab.mercurial-scm.org/D644
Before this patch, `rebase --abort` may fail to do the cleanup:
$ hg rebase --abort
rebase aborted (no revision is removed, only broken state is cleared)
The added test case makes sure `--abort` works in this case.
Differential Revision: https://phab.mercurial-scm.org/D643
Since the redundant commit during the amend has been been removed, there is no
need for commit callback function in amend now. Therefore, this commit removes
the unused parameter "commmitfunc" which was being used for this purpose.
Test Plan:
Ensured that all the tests pass
Differential Revision: https://phab.mercurial-scm.org/D635
The return values from wrapfunction() were never used here. Using the
value is also a little tricky and wrappedfunction() should be
preferred, so let's just delete the assignments.
There's also a bunch of return values from wrapcommand() being
assigned to a variable here, but at least that value can be (and is
used after some of the assignments).
Differential Revision: https://phab.mercurial-scm.org/D618
Changes the API of `ui.edit()` to take an optional `action` argument,
which is used when constructing the suffix of the temp file.
Previously, it was possible to set the suffix by specifying a `suffix` to the
optional `extra` dict that was passed to `ui.edit()`, but the goal is to
drop support for `extra.suffix` and make `action` a required argument.
To this end, `ui.edit()` now yields a `develwarn()` if `action` is not set
or if `extra.suffix` is set.
I updated all calls to `ui.edit()` I could find in `hg-crew` to specify the
appropriate `action`. This means that when creating a commit, instead
of the path to the editor file being something like:
`/tmp/hg-editor-XXXXXX.txt`
it is now something like:
`/tmp/hg-editor-XXXXXX.commit.hg.txt`
Some editors (such as Atom) make it possible to statically define a [TextMate]
grammar for files with a particular suffix. For example, because Git reliably
uses `.git/COMMIT_EDITMSG` and `.git/MERGE_MSG` as the paths for commit-type
messages, it is trivial to define a grammar that is applied when files of
either name are opened in Atom:
https://github.com/atom/language-git/blob/v0.19.1/grammars/git%20commit%20message.cson#L4-L5
Because Hg historically used a generic `.txt` suffix, it was much harder to
disambiguate whether a file was an arbitrary text file as opposed to one
created for the specific purpose of authoring an Hg commit message.
This also makes it easier to add special support for `histedit`, as it has its own
suffix that is distinct from a commit:
`/tmp/hg-histedit-XXXXXX.histedit.hg.txt`
Test Plan:
Added an integration test: `test-editor-filename.t`.
Manually tested: ran `hg ci --amend` for this change and saw that it
used `/tmp/hg-editor-ZZjcz0.commit.hg.txt` as the path instead of
`/tmp/hg-editor-ZZjcz0.txt` as the path.
Verified `make tests` passes.
Differential Revision: https://phab.mercurial-scm.org/D464
Previously, obsoleted revs with successors in destination are completely
ignored. That caused some inconvenience when working copy is obsoleted. Most
commands avoid working copy being obsoleted, but `hg pull` is an exception.
This patch makes rebase able to move bookmarks or working parent for those
obsoleted revs. It does so by keeping the obsoleted revs in `state` and
marking them as "skipped, rebased to desired destination" during run-time.
This reverts part of the behavior change of 80d53a39fbcc and D24.
Differential Revision: https://phab.mercurial-scm.org/D527
`rev` being "skipped" could currently be caused by moving `rev` does not
create a new commit. In this case, `state[rev]` is already changed to `p1`,
and is a sane destination for bookmark or working parent movement. Therefore
an additional destination adjustment is unnecessary.
Differential Revision: https://phab.mercurial-scm.org/D565
Previously rebase source and destination could not overlap. But with the
multi-destination support, source and destination could reasonably partially
overlap. That requires another topological sort on `{sourcerev: destrev}`
graph (destmap). This patch implements that.
If a revision's destination is itself, the error message gets changed from
"source is ancestor of destination" to "source and destination form a
cycle". Not marking as BC since automation should depend on exit code, not
error message.
Differential Revision: https://phab.mercurial-scm.org/D470
This patch defines `SRC` (a single source revision) and `ALLSRC` (all source
revisions) to be valid names in `--dest` revset if `--src` or `--rev` is
used. So destination could be defined differently according to source
revisions. The names are capitalized to make it clear they are "dynamically
defined", distinguishable from normal revsets (Thanks Augie for the
suggestion).
This is useful, for example, `-r 'orphan()' -d 'calc-dest(SRC)'` to solve
instability, which seems to be a highly wanted feature.
The feature is not completed, namely if `-d` overlaps with `-r`, things
could go wrong. A later patch will handle that case.
The feature is also gated by `experimental.rebase.multidest` config option
which is default off.
Differential Revision: https://phab.mercurial-scm.org/D469
A later patch will add multiple destination support. This patch changes
internal state and the rebase state file format to support that. But the
external interface still only supports single destination.
A test was added to make sure rebase still supports legacy state file.
The new state file is incompatible with old clients. We had done similar
state file format change before: 5eac7ab, 92409f8, and 72412af. The state
file is transient, so the impact of incompatibility is limited. Besides,
the old client won't support multiple destinations anyway so it does not
really make sense to make the file format compatible with them.
Differential Revision: https://phab.mercurial-scm.org/D348
The old code stores successors of all related nodes together, which works
fine if destination is unique. A future patch would make destination
non-unique so let's change the implementation to test successors for
rebaseset separately.
Differential Revision: https://phab.mercurial-scm.org/D347
Since this extension is fairly new for almost all the contributors, remembering
the admonition (with titles) is difficult. The list (-l) flag provides
a list of all the active admonitions along with titles.
For usage, hg releasenotes -l returns the list.
Differential Revision: https://phab.mercurial-scm.org/D454
Writing journal files using `atomictemp` leads to quadratic performance that
could be problematic if automation runs many commands. Other logs like
blackbox does not use atomictemp, and journal logs are not critical for repo
correctness. So let's make them non-atomictemp.
Differential Revision: https://phab.mercurial-scm.org/D517
While using releasenotes extension, we will be using admonitions in commit messages.
The check (-c) flag will look for an admonition within the message. If it exists, it will
verify if it is stated under default or custom admonition. The check fails if the
admonition is not present in any of them. It also suggests similar admonitions
in case the admonition is invalid.
Differential Revision: https://phab.mercurial-scm.org/D368
When the code executes to _finishrebase, self.state should be populated with
correct destinations and do not need to be written to a node. The code was
introduced by 8dc45c9059, which seems to avoid setting state values to None
but it didn't provide more details.
Differential Revision: https://phab.mercurial-scm.org/D346
Previously, when there are 2 merge base candidates, we choose p1 blindly,
which may make the merge result to have "unwanted content". This patch makes
rebase smarter - choose a merge base that does not have "unwanted revs" if
possible. Since we don't really have a good solution when there are
"unwanted revs", abort in that case.
Differential Revision: https://phab.mercurial-scm.org/D340
The "source" variable is calculated inside a loop but it does not depend on
loop variables. Therefore move it outside the loop.
Differential Revision: https://phab.mercurial-scm.org/D345
Now the minimal value of state is revtodo, that condition is always true,
therefore removed.
Differential Revision: https://phab.mercurial-scm.org/D344
They are no longer necessary to make rebase behavior correct. Therefore
remove them to make the code cleaner and easier to reason about.
Differential Revision: https://phab.mercurial-scm.org/D26
These states will be removed to make the code cleaner and more robust.
Remove their messages first to make review easier.
Differential Revision: https://phab.mercurial-scm.org/D25
Those states are no longer necessary for rebase to function properly. Remove
them to make the code cleaner.
Marked as BC because in a corner case where working parent is obsoleted, and
is skipped for rebase, we no longer move working parent after rebase
completes. That is better since if working parent is obsoleted, it should be
the user moving working parent back there (after a rebase) explicitly, in
that case, we shouldn't move working parent again.
Differential Revision: https://phab.mercurial-scm.org/D24
A later patch will clean up those states. This patch moves the messages
earlier.
Marked as BC since the order of message has changed.
Differential Revision: https://phab.mercurial-scm.org/D23
In order to make this work, we have to wrap the io streams in a
TextIOWrapper so that __builtins__.input() can do unicode IO on Python
3. We can't just restore the original (unicode) sys.std* because we
might be running a cmdserver, and if we blindly restore sys.* to the
original values then we end up breaking the cmdserver. Sadly,
TextIOWrapper tries to close the underlying stream during its __del__,
so we have to make a sublcass to prevent that.
If you see errors like:
TypeError: a bytes-like object is required, not 'str'
On an input() or print() call on Python 3, the substitution of
sys.std* is probably the root cause.
A previous version of this change tried to put the bytesinput() method
in pycompat - it turns out we need to do some encoding handling, so we
have to be in a higher layer that's allowed to use
mercurial.encoding.encoding. As a result, this is in util for now,
with the TextIOWrapper subclass hiding in encoding.py. I'm not sure of
a better place for the time being.
Differential Revision: https://phab.mercurial-scm.org/D299
The old error message "cannot use revision REV as base, result would have 3
parents" is confusing - why use REV as base? why add a new parent?.
This patch changes it to "cannot move parent", which seems better.
Differential Revision: https://phab.mercurial-scm.org/D342
"defineparents" is the core algorithm of rebase. The old code has too many
tech debts (like outdated comments, confusing assertions, etc) and is very
error-prone to be improved. This patch rewrites "defineparents" to make the
code easier to reason about, and solve a bunch of issues, including:
- Assertion error: no base found (demonstrated by D212, issue5578)
- Asymmetric result (demonstrated by D211, "F with one parent")
- Wrong new parent (demonstrated by D262, "C':A'A'")
- "revlog index out of range" (demonstrated by D262, issue5630)
- "nothing to merge" (demonstrated by D262)
As a side effect, merge base decision has been made more solid - rebase now
prints out explicitly what could go wrong when it cannot find a unique
suitable merge base.
.. fix:: Issue 5578, Issue 5630
Core rebase algorithm has been rewritten to be more robust.
Differential Revision: https://phab.mercurial-scm.org/D21
Without the change, the error looks like:
warning: Watchman unavailable: "watchman" executable not in PATH (%s),
while executing [Errno 2] No such file or directory
With the change, it now looks like:
warning: Watchman unavailable: "watchman" executable not in PATH
([Errno 2] No such file or directory)
Differential Revision: https://phab.mercurial-scm.org/D322
This method was added in 6fb54510b150. AFAICT it didn't do anything at
inception. If it did, there was no test coverage for it because
changing it to raise doesn't fail any tests at that revision.
3bcb9f9a4a63 later refactored all remote.batch() calls to
remote.iterbatch(). So if this was somehow used, it isn't called
any more because there are no calls to .batch() remaining in the
repo.
I suspect the original patch author got confused by the distinction
between the peer/remote interface and the largefiles store. The lf
store is a gateway to a peer instance. It exposes additional
lf-specific methods to execute against a peer. However, it is not
a peer and doesn't need to implement batch() because peer itself
does that.
Differential Revision: https://phab.mercurial-scm.org/D316
If someone changes "pick" to "roll" or "fold" for the first
changeset in a histedit rule Mercurial could remove a wrong
changeset if the phase is non-public.
roll or fold for the first changeset should be invalid.
It is possible that the incoming note fragments have some similar content as the
existing release notes. In case of a bug fix, we match for issueNNNN in the
existing notes. For other general cases, it makes use of fuzzywuzzy library to get
a similarity score. If the score is above a certain threshold, we ignore the
fragment, otherwise add it. But the score might be misleading for small commit
messages. So, it uses similarity function only if the length of string (in words)
is above a certain value. The patch adds tests related to its usage. But it needs
improvement in the sense of combining incoming notes. We can use interactive mode
for adding notes. Maybe we can do this if similarity is under a certain range.
This commit makes it so sparse treats passed paths as CWD-relative,
not repo-root-realive. This is a more intuitive behavior in my (and some
other FB people's) opinion.
This is breaking change however. My hope here is that since sparse is
experimental, it's ok to introduce BCs.
The reason (glob)s are needed in the test is this: in these two cases we
do not supply path together with slashes, but `os.path.join` adds them, which
means that under Windows they can be backslashes. To demonstrate this behavior,
one could remove the (glob)s and run `./run-tests.py test-sparse.t` from
MinGW's terminal on Windows.
This was previously landed as 4bc0c14fb501 but backed out in b63351f6a2 because
it broke hooks mid-rebase and caused conflict resolution data loss in the event
of unexpected exceptions. This new version adds the behavior back but behind a
config flag, since the performance improvement is notable in large repositories.
The old commit message was:
Recently we switched rebases to run the entire rebase inside a single
transaction, which dramatically improved the speed of rebases in repos with
large working copies. Let's also move the dirstate into a single dirstateguard
to get the same benefits. This let's us avoid serializing the dirstate after
each commit.
In a large repo, rebasing 27 commits is sped up by about 20%.
I believe the test changes are because us touching the dirstate gave the
transaction something to actually rollback.
(grafted from 9e3dc3a1638b9754b58a0cb26aaa75d868058109)
(grafted from 7d38b41d2266d9a02a15c64229fae0da5738dcec)
Differential Revision: https://phab.mercurial-scm.org/D135
The code was refactored during the move to be more procedural
instead of using string formatting. This has the benefit of not
writing empty sections, which changed tests.
The sparse extension maintains caches for the sparse files
to a signature and a signature to a matcher. This allows the
sparse matchers to be resolved quickly, which is apparently
something that can occur in loops.
This patch ports the sparse caches to the localrepo class
pretty much as-is. There is potentially room to improve the
caching mechanism. But that can be done as a follow-up.
The default invalidatecaches() now clears the relevant sparse
cache. invalidatesignaturecache() has been moved to sparse.py.
This method is reasonably well-contained and simple to move.
As part of the move, some light formatting was performed.
A "working copy" reference in an error message was changed to
"working directory."
The biggest change was to _refreshoncommit() in sparse.py. It
was previously checking for the existence of an attribute on
the repo instance. Since the moved function now returns empty
data if sparse isn't enabled, we unconditionally call the
new function. However, we do have to protect another method
call in that function. This will all be unhacked eventually.
Currently, the sparse extension sniffs repo instances for
attributes defined by the sparse extension to determine if
sparse is enabled. As we move code away from repo instances,
these checks will be a bit more brittle.
We introduce a module-level variable to track whether sparse is
enabled as a temporary workaround.
One more step towards weaning off methods on repo instances and
moving code to core. While this function is only used once and
is simple, it needs to exist on its own so Facebook can monkeypatch
it to enable simplecache integration.
This patch marks the beginning of moving code from the sparse
extension into core. The goal is to move as much of the
functionality as possible into core, where it will be an
experimental feature. The extension will likely continue to
exist to enable the feature and provide UI elements.
As part of the move, the repo method was converted to a module
function. It doesn't need to exist on repos.
An error message was also updated to reflect that an error isn't
necessarily from the .hg/sparse file. The API should be updated
later to pass in a filename so the error can be more descriptive.
Copyright of the added file was copied from the sparse extension.
