Summary:
This greatly simplifies the implementation, too.
*updatetotally() change:*
`hg up` now passes a brev of `None` if the `--inactive` flag was passed. This avoids activating the bookmark if one was passed. However, it still needs to deactivate the active bookmark, if there was one. After looking at the existing code, I think it was just wrong.
The rest of this is just cleanup.
Reviewed By: markbt
Differential Revision: D10376544
fbshipit-source-id: e5ad8aa01acab906db4d3fc09c6450e3c48b59fb
Summary: Update references in core mercurial to use repo.localvfs instead of repo.vfs.
Reviewed By: quark-zju
Differential Revision: D9699162
fbshipit-source-id: 0401677d2b0a1340e66cffb7ee907a0d93aa6717
Summary:
The test reveals some ordering issue with clone failure handling.
`destrepo.close()` could have side effects writing files. So let's do that
before removing the destination repo.
Reviewed By: DurhamG
Differential Revision: D8869843
fbshipit-source-id: 4cf97038dd4545a59dcee3d86bb114efd5794e62
Summary:
A future diff will make us depend on repo.close() being called to
finalize the writing of some tree data. It turns out we didn't call close on the
destination repo during a clone, which caused some tests to change. Let's call
close on that repo to prevent a test change in the next diff.
Reviewed By: phillco
Differential Revision: D8670680
fbshipit-source-id: ad63ccfc51ec4c3de2dad494fdb1ae8f6ba8e40a
Summary: Mostly empty lines removed and added. A few bugfixes on excessive line splitting.
Reviewed By: quark-zju
Differential Revision: D8199128
fbshipit-source-id: 90c1616061bfd7cfbba0b75f03f89683340374d5
Summary:
Turned on the auto formatter. Ran `arc lint --apply-patches --take BLACK **/*.py`.
Then run `arc lint` again so some other autofixers like spellchecker etc. looked
at the code base. Manually accept the changes whenever they make sense, or use
a workaround (ex. changing "dict()" to "dict constructor") where autofix is false
positive. Disabled linters on files that are hard (i18n/polib.py) to fix, or less
interesting to fix (hgsubversion tests), or cannot be fixed without breaking
OSS build (FBPYTHON4).
Conflicted linters (test-check-module-imports.t, part of test-check-code.t,
test-check-pyflakes.t) are removed or disabled.
Duplicated linters (test-check-pyflakes.t, test-check-pylint.t) are removed.
An issue of the auto-formatter is lines are no longer guarnateed to be <= 80
chars. But that seems less important comparing with the benefit auto-formatter
provides.
As we're here, also remove test-check-py3-compat.t, as it is currently broken
if `PYTHON3=/bin/python3` is set.
Reviewed By: wez, phillco, simpkins, pkaush, singhsrb
Differential Revision: D8173629
fbshipit-source-id: 90e248ae0c5e6eaadbe25520a6ee42d32005621b
Summary:
Update hg.copystore and util.copyfiles to use the new-style progress bar
context manager.
Reviewed By: ryanmce
Differential Revision: D7329482
fbshipit-source-id: 4ac1def57e0ae4e7819c7c0c4d6f1715b8cbb625
Summary:
verify.skipmanifests was added to let us skip the parts of verify that
were expensive in a lazy-manifest world. We also need to skip .hgsubstate
verification since it requires the manifests.
Reviewed By: singhsrb
Differential Revision: D7127353
fbshipit-source-id: 377fffb8556f7578da3e51c3da53f97554fb5d74
Summary:
Currently, commits adding LFS files are not verified server-side since the LFS
extension explicitly skips hash checking during unbundle, to avoid overhead
downloading/reading LFS objects.
We'd like those commit hashes to be verified. However, the existing verify
command does not scale with a huge repo. So let's add `verify -r REV` support
to be able to incrementally verify a repo.
Reviewed By: quark-zju
Differential Revision: D6947227
fbshipit-source-id: 6ffda3a814822942630339fc7de62c3fcb284fda
Summary:
This was blocking us default-enabling `fbsparse`; however, this function is actually incredibly fragile and can break with a variety of extensions enabled (even blackbox).
E.g., try this on the latest release and you'll get an exception!
```
cd $(mktemp -d); hg init a; hg share a b; cd b; hg unshare
```
That particular breakage is called by blackbox trying to look at `repo[None]` to do some logging, but anything that tries to read `repo.dirstate` after this will print the exception. The root cause is this line which is trying to override `repo.root`:
```
repo.unfiltered().__init__(repo.baseui, repo.root)
```
It's trying to update the repo's path to indicate that it is independent and no longer shared. But, the initializer isn't really designed to be called twice, AFAICT, and doing so here leaves the property caches out of sync with properties of the repo (namely `_filecache`).
Durham's suggestion was just to nuke `hg unshare`. This patch works around it for now, though, in case we want to keep it alive.
Reviewed By: quark-zju
Differential Revision: D6758397
fbshipit-source-id: 90d3773d9340f2a5b2e6e900a2194d8b931f410d
Make 'hg outgoing' respect "paths.default:pushurl" in addition to
"paths.default-push".
'hg outgoing' has always meant "what will happen if I run 'hg push'?" and it's
still documented that way:
Show changesets not found in the specified destination repository or the
default push location. These are the changesets that would be pushed if a
push was requested.
If the user uses the now-deprecated "paths.default-push" path, it continues to
work that way. However, as described at
https://bz.mercurial-scm.org/show_bug.cgi?id=5365, it doesn't behave the same
with "paths.default:pushurl".
Why does it matter? Similar to the bugzilla reporter, I have a read-only mirror
of a non-Mercurial repository:
upstream -> imported mirror -> user clone
^-----------------------/
Users push directly to upstream, and that content is then imported into the
mirror. However, those repositories are not the same; it's possible that the
mirroring has either broken completely, or an import process is running and not
yet complete. In those cases, 'hg outgoing' will list changesets that have
already been pushed.
Mozilla's desired behavior described in bug 5365 can be accomplished through
other means (e.g. 'hg outgoing default'), preserving the consistency and
meaning of 'hg outgoing'.
This patch renames remotenames.py to logexchange.py, test-remotenames.t to
test-logexchange.t. Also this patch renames the directory in which the data is
stored from remotenames to logexchange. After this patch, data about bookmarks
and branches from a server we pull is stored in
`.hg/logexchange/(bookmarks|branches)` files.
Thanks to smf for the suggestion.
Differential Revision: https://phab.mercurial-scm.org/D1607
If `experimental.remotenames` is set to True, we store the remotenames in case
of `hg pull`. This patch adds that support to clone command also.
Differential Revision: https://phab.mercurial-scm.org/D1601
I think there's a slight hole here in that a subrepo could be shared, removed
from .hgsub, and then it's not part of context.substate (so not iterated over).
But the push command has the same hole IIRC, and I think removing a subrepo is
an edge case.
The import hack is a copy/paste of subrepo.subrepo().
This will be used to setup unsharing subrepos. Usually cmdutil is used for
this purpose. But the implementation needs hg.copystore(), and the hg module
already imports cmdutil.
Previously, only the top level repo was shared, and then any subrepos were
cloned on demand. This is problematic because commits to the parent repo would
write an updated .hgsubstate to the share source, but the corresponding subrepo
commit would be stuck in the local subrepo. That would prevent an update in the
source repo. We already go to great lengths to avoid having inconsistent repos
(e.g., `hg push -r rev` will push _everything_ in a subrepo, even if it isn't
referenced in one of the parent's outgoing commits). Therefore, this seems like
a bug fix, and there's no option to get the old behavior. I can't imagine the
previous behavior was useful to anybody.
There shouldn't be an issue with svn, since it is centralized. Maybe --git-dir
can be used for git subrepos, but I'll leave that to someone more familiar with
git.
An integer was previously being implicitly returned from commands.share(), which
caused dispatch() to start crashing when changing over to returning the shared
repo. All error paths appear to raise, so this can be hardcoded to success.
The clone command checks for 'is None' in a similar pattern, but since
hg.clone() always returns a tuple, that seems wrong?
.. fix:: Issue 5675
Creating a share of a repository with a Mercurial subrepository will now
share the subrepository.
and
.. bc::
Mercurial subrepositories are now shared instead of cloned when the parent
repository is shared. This prevents dangling subrepository references in the
share source. Previously shared repositories with cloned subrepositories
will continue to function unchanged.
experimental.updatecheck was renamed into commands.update.check, use the
config system to provides the fallback on the old config name instead of
adding more code.
Differential Revision: https://phab.mercurial-scm.org/D1117
.. feature::
New `commands.update.check` feature to adjust constraints on when
`hg update` will allow updates with a dirty working copy.
also
.. bc::
The `experimental.updatecheck` name for the new `commands.update.check`
feature is now deprecated, and will be removed after this release.
Differential Revision: https://phab.mercurial-scm.org/D1070
We were using str because on Python 2, str were bytes but now we have to use
bytes. Otherwise the if conditions fails and we have weird results from commands
on Python 3.
Right now, the clone only copies the branchmap caches. There are multiple
other valuable caches that we should copy and extensions might add their own.
So we add a function to list the cache files to copy from the repository. The
repository argument is unused but extensions will want it.
chg needs special logic around repo object creation (like, collecting and
reporting repo path to the master server). Adding "reposetup" to
dispatch.request seems to be an easy and reasonably clean way to allow that.
outgoing has been using an unfiltered repo since 07f64d64baf7 (discovery:
outgoing pass unfiltered repo to findcommonincoming (issue3776),
2013-01-28). If I'm reading code and history correctly, it should be
safe to run _outgoing() on a filtered repo since daf83ddd4afd
(discovery: run discovery on filtered repository, 2015-01-07). By
running _outgoing() on a filtered repo, we can also remove the
workaround there for ignoring filtered revisions.
Now that the 'vfs' classes moved in their own module, lets use the new module
directly. We update code iteratively to help with possible bisect needs in the
future.
This allows the user to set e.g. experimental.updatecheck=abort to
abort update if the working directory is dirty, but still be able to
override the behavior with e.g. --merge when needed.
I considered adding a --mergelinear option to get back the old
behavior even when experimental.updatecheck=abort is set, but I
couldn't see why anyone would prefer that over --merge.
The default is read in hg.updatetotally(), which means it also applies
to "hg pull -u" and "hg unbundle -u".
Storing a relative path the source repository is useful when exporting
repositories over the network or when they're located on external
drives where the mountpoint isn't always fixed.
Currently, Mercurial interprets paths in `.hg/shared` relative to
$PWD. I suspect this is very much unintentional, and you have to
manually edit `.hg/shared` in order to trigger this behaviour.
However, on the off chance that someone might rely on it, I added a
new capability called 'relshared'. In addition, this makes earlier
versions of Mercurial fail with a graceful error.
I should note that I haven't tested this patch on Windows.
The function has a "check" parameter that's currently unused, and it
makes sense to me to have it honor it. That way other callers than
commands.update() could set it if they needed.
Before, if performing a clone+share from a repo that was itself
using shared storage, the share code would copy paths.default from
the underlying repo being shared, not from the source given by
the user.
This patch teaches hg.clonewithshare to resolve paths.default
and pass it to share so it can be written to the hgrc accordingly.
We label bookmark name as such in various messages. This will help them to
standout (or at least give the user the option to make them stand out). We use a
distinct label for the 'active' bookmark, this can help users to catch bookmark
operation affecting their working copy.
In this case, column positioning isn't needed for i18n, too.
Maybe, check-code warning "missing _() in ui message" caused this
useless _() invocation in 6477dd5eeedf.
TIL that ui instances for remote/peer repos don't automagically inherit
config options from .hg/hgrc files.
This patch makes remote ui instances inherit options from the
[hostsecurity] section. We were already inheriting options
from [hostfingerprints] and [auth]. So adding [hostsecurity] to the
list seems appropriate.
