Summary:
always pull only accessed bookmarks and default, do not take remote books from `remotenames` file
also adding handling of `CorruptedState` error to delete `selectivepullaccessedbookmarks` file in that case. it will help mercurial not to crash in case the file was corrupted and self-fix next time.
Reviewed By: mitrandir77
Differential Revision: D16079548
fbshipit-source-id: a2983ee63fb17d2922f3c230c3d6e36aa6591b62
Summary:
The changes from commit cloud sync are supposed to be applied in-memory and committed with cloudsync-transaction to the disk. For example, for bookmarks the changes first are applied to the existing dict of bookmarks and with the transaction are being written to the disk into the `bookmarks` file.
Ideally I need to have similar thing for remote bookmarks. However, the current implementation provides of remotenames only read-only store with only possibilty to change something on the disk (`remotenames` file) and upload it to memory.
We're planning to rewrite the whole extension at some point, but currently to move forward I added a new method to the store, which will apply changes to the `remotenames` file and reload the remotenames store.
It's not transactional and uses existing function `saveremotenames`, which I refactored a little bit, so it could apply changes for multiple remotes at the same time. I also removed deletion of `remotedistance` file as it is deprecated and not used a long time.
Reviewed By: markbt
Differential Revision: D15921983
fbshipit-source-id: d6b2638db689c0c1b66a6291fc9f0f2c9dac978c
Summary:
Enabled selective pull for myself and found issue with the passing positional args in the remotename wrapper of `exchange.py:pull(..)`.
`hg pull` failed because `heads` were passing uboth as positional args and as kwaargs. Fixed the issue explicitly specified args of the function.
Reviewed By: mitrandir77
Differential Revision: D15855502
fbshipit-source-id: 91b9bcfc122db069f9c6382e50f3185736103202
Summary:
Selective pull, when just enabled, will filter only remote bookmark for the active remote repo at that time. When user will try to pull next time from the different remote, bookmarks for that remote won't be filtered, because the selective pull will think that it's already enabled and the remotenames file already has only interesting bookmarks.
I changed `selectivepullenabled` file to keep track of the remotes which selectivepull has been enabled for.
Reviewed By: markbt
Differential Revision: D15583506
fbshipit-source-id: dec09baf1e1a0c80d1d5987ac6f85fe1202b2dab
Summary: Now slective pull, when enabled, will keep not only configured remote bookmarks, but accessed, that were recoreded earlier, as well.
Reviewed By: markbt
Differential Revision: D15583505
fbshipit-source-id: 8c8d300afc333a94427513d9844c1c1af3cf7f32
Summary:
If selective pull is enabled, the old implementation of `--remote` doesn't show all available remote bookmarks, but only locally available ones.
New implementation uses `listkeys` API to fetch remote bookmarks from the server.
However because `remote-path` flag belongs to the infinitepush extension, if the extension is not enabled, than `--remote` will show only bookmarks from the default remote.
Reviewed By: markbt
Differential Revision: D15547513
fbshipit-source-id: b7c79a0cc7237bbf086c64a71d6ed313aa520582
Summary:
With selective pull feature we need to have ability to list locally available remote bookmarks - the bookmarks the user is subscribed to.
As current implementation of `--remote` does exactly that, pointing subscription to the same implementation.
Reviewed By: markbt
Differential Revision: D15547515
fbshipit-source-id: d3ac7295fee3391076855fbe1bed00124dab973f
Summary: When selective pull will be enabled, `hg log` won't be able to show any information about the remote bookmarks that are not in subscriptions for particular user. So we need to hint the user that they may want to explicitly pull the remote bookmark first, if hg log fails to find it.
Reviewed By: quark-zju
Differential Revision: D15516462
fbshipit-source-id: 5be77b0048d8e175a737f76a8e89768f4c837f60
Summary:
Make the code for calculating which revisions the `-B` options to `hg prune`
and `hg debugstrip` affect common to both commands.
The remotenames modification of `repair.stripbmrevset` is wrong. It should
exclude all ancestors of commits that have remotenames, not just those that
don't share a bookmark with the remotename. Fix it.
Reviewed By: quark-zju
Differential Revision: D15562716
fbshipit-source-id: 507002505100e7d60c395f242cc8e1062b91cc20
Summary:
We have seen reports of this file getting corrupt on Windows when
peoples' machines are hard-rebooted. Handle that corruption with a
more helpful error message.
Reviewed By: quark-zju
Differential Revision: D15506345
fbshipit-source-id: 66d998a156bc11953b5afb440270ff77af4677fc
Summary: Do not try to update accessed bookmarks file if there wasn't pulled bookmarks. Currently it rewrites the file even with an empty list of bookmarks.
Reviewed By: quark-zju
Differential Revision: D15165791
fbshipit-source-id: 8eb3b137332c741324b9da9455e3d0dba31bbeda
Summary: Remotenames are shared between the shared repos. The enabled file should be stored in the same place so the config change would be consistent for all the checkouts.
Reviewed By: quark-zju
Differential Revision: D15165789
fbshipit-source-id: c08af95a6b3e5d391cdf8b3ae8ef9b8e3514dbe4
Summary:
File that tracks accessed bookmarks doesn't interact with anything else and doesn't really need repo.wlock. However if does use wlock, hg commands like `hg log -r`, which normally are read-only, start waiting for the lock and thus are blocked by other writing commands, that might be running in different checkouts of the same repo.
Let's use a different lock for this feature.
Reviewed By: simpkins
Differential Revision: D15165788
fbshipit-source-id: f04c7196d51db67069c6420545be24d2b7c0af27
Summary: Added logging of a number of the currently tracked accessed remote bookmarks.
Reviewed By: mitrandir77
Differential Revision: D15080683
fbshipit-source-id: c03c417afcd24683998689365c893d9e16f265f8
Summary:
Track remote names that are used as destination for hg update.
Resolving name in the repo happens actually twice: as validation during parsing and tokenization of the given specs and actual resolving. This is still fine to update file with used bookmarks twice, because the update/pull operations are much heavy, and updating the file won't make things much slower. Implementing kind-of-cache for used remote names so we could update the file once, isn't worth it, as the feature will be temporarily enabled and won't be needed after the selective pull rollout.
Reviewed By: markbt
Differential Revision: D15048105
fbshipit-source-id: 5b03443a6ab349e3bd88613d21e7b1efdc1ff6cf
Summary: `accessed(..)` method will allow to log the fact of a name access, that is needed to track interesting remotenames.
Reviewed By: markbt
Differential Revision: D15047919
fbshipit-source-id: 29566653e742b3f24b742ffce2282baed833ea61
Summary:
Tracking remote bookmarks that was pulled with
```
hg pull -B <remote name>
```
All these remotenames, if they exist, will be stored in `.hg/selectivepullusedbookmarks` file.
It will allow us to estimate how much memory do we need to keep remote names in sync state in Commit Cloud and automatically mark collected remote bookmarks as "interesting" when the selective pull will be enabled.
Reviewed By: markbt
Differential Revision: D14912903
fbshipit-source-id: 3001869175553327c0840e2cfb829724dfd82893
Summary:
pushrebase, infinitepush, remotenames, hgsubversion, and hggit wrap the
push command in very complicated ways. For instance, if hgsubversion push runs,
it will never call the original push command, and therefore if its wrapper gets
called first none of the other code gets executed. Unfortunately the opposite
can also be true, where the other extensions may make decisions that ultimately
prevent the hgsubversion code from running. I believe this is the cause of our
recent issue where someone pushed directly to hg from an svn backed repo.
The real fix is to clean up our mess of push commands, but for now we can
at least prevent remotenames from avoiding the hgsubversion push path entirely.
I believe this used to work more reliably before D14153207. In that diff it
changed the behavior from passing "None" as the destination (which is what was
passed in originally) to passing the actual url. The remotename code has some
logic that says "if the passed in destination is None, default, or default-push,
check if its svn/git and call orig". By passing in the actual url, this logic is
bypassed and we can head straight to the remotenames push code which may call
exchange.push and begin a vanilla push.
The easy fix is to just validate the passed in url directly if it exists and
call orig if its svn or git.
Reviewed By: quark-zju
Differential Revision: D15075782
fbshipit-source-id: 10c9c1c5669ff647a03987a2de5eaf1e3b474ce0
Summary:
The `if dest` test fails with infinitepush changing `dest` to non-None.
Fix it by also checking if `dest` matches `default-push` (or `default`).
Reported by: fryfrog
Reviewed By: markbt
Differential Revision: D14965995
fbshipit-source-id: 91e68368eda4457d06059387307a9572bc6d2906
Summary:
Callers may call `remotenames.activepath` with the remote as a string URL. For
remotenames we must normalize these paths as we do for remotes that are passed
in as objects, for the same reason as in D14051479.
Differential Revision: D14621090
fbshipit-source-id: 8a02e9554039ad3daf3093001889cf1746ce395a
Summary:
Fixes the below type error when pulling from a git repo using hg-git on my laptop:
File "edenscm/hgext/remotenames.py", line 225, in expull
pullremotenames(repo, remote, bookmarks)
File "edenscm/hgext/remotenames.py", line 314, in pullremotenames
path = activepath(repo.ui, remote)
File "edenscm/hgext/remotenames.py", line 1464, in activepath
rpath = _normalizeremote(remote.url)
File "edenscm/hgext/remotenames.py", line 1439, in _normalizeremote
u = util.url(remote)
File "edenscm/hgext/hggit/__init__.py", line 164, in _url
if not (path.startswith(pycompat.ossep) and ":" in path):
AttributeError: 'function' object has no attribute 'startswith'
Basically, `peer.url()` is the API, `peer._url` is a private field that does
not always exist somehow.
Besides, further remove named branches that can crash hg-git with
NotImplementedError:
File "edenscm/hgext/remotenames.py", line 225, in expull
pullremotenames(repo, remote, bookmarks)
File "edenscm/hgext/remotenames.py", line 322, in pullremotenames
for branch, nodes in remote.branchmap().iteritems():
File "edenscm/hgext/hggit/gitrepo.py", line 73, in branchmap
raise NotImplementedError
Reviewed By: DurhamG
Differential Revision: D14144462
fbshipit-source-id: 2e886c639cf6689480f84626eaf0d5ec25512ea0
Summary:
Subrepo is another unloved features that we don't want to support.
Aggressively remove it everywhere, instead of just turning off configs.
I didn't spend much time to split this commit so it's smaller and more friendly
to review. But it seems tests are passing.
Reviewed By: sfilipco
Differential Revision: D14220099
fbshipit-source-id: adc512a047d99cd4bafd0362e3e9b24e71defe13
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:
`push --new-branch` is very rarely used and it does not make much sense with
checkheads removed (D14179861). Remove it everywhere.
There is still [one user](https://fburl.com/t5hmcxrp) of the
`push --new-branch` flag. Do not remove it just yet.
Reviewed By: singhsrb
Differential Revision: D14212180
fbshipit-source-id: 18f80576ab6464fc36b047a8a35b339231ee9d8e
Summary:
When using query strings or fragments in an URL we should treat repository paths
as the same repo. This allows servers to use query strings for metadata, without
treating the urls as different servers. By introducing normalization in our grouping,
we will consider the normalized result to be the qualifier for what is the same repo,
rather then the full absolute path - which includes query strings and fragments.
Reviewed By: DurhamG
Differential Revision: D14051479
fbshipit-source-id: c82fe041467f6bd6af210688c0be873e2da93781
Summary: Named branches are going away. Remove the logic around it.
Reviewed By: phillco
Differential Revision: D13978575
fbshipit-source-id: d6e28d7cadffa612f74a2afc12800829d6113dfa
Summary:
Currently if default path and infinitepush both point to the remote path
from the repo, the activepath function returns 'infinitepush' rather than
'default' because of the logic I have fixed.
It makes your smartlog looks like.
```
o 037dddb5 62 minutes ago infinitepush/fbobjc/stable remote/fbobjc/stable
.
o 66e0e00c Today at 05:58 infinitepush/fbandroid/stable
remote/fbandroid/stable
.
@ 28c3b5b0 Today at 05:40 mlesyk D14003881 T27597699
. [fbar][prod_role] fix region detection part
.
o 407504d6 Today at 04:58 infinitepush/fbsource/stable
remote/fbsource/stable
```
When you pull it updates infinitepush/master, etc instead of remote/master,
etc.
This only happens if they both point to the same url.
This is not desirable for infinitepush.
I also introduced infinitepush-other that we will use for the secondary commit cloud backend.
It would have the same issue if it matches the url of the default path.
Reviewed By: markbt
Differential Revision: D14005639
fbshipit-source-id: f3ea8098e1c418e2efd43b5430bb4252f6ad6b2c
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
