Summary:
Set the `component` to `"commitcloud"` for commit cloud statuses and
messages, rather than using custom highlight functions.
Reviewed By: quark-zju
Differential Revision: D15201944
fbshipit-source-id: 7635942a5ca029209711a2b89c32cc5fd677d22f
Summary:
Add support for explicit visibility tracking in commit cloud sync.
This means commit cloud reads the visibleheads and syncs these with the commit
cloud heads directly, removing the source of problems where obsmarkers disagree
on different hosts.
Commit cloud requires that the ordering of heads is maintained to get stable
ordering of new commits. Update the visibleheads tracking to maintain
ordering, rather than using sets.
Finally, the calculation of the replacement node was slightly off. This was
revealed in the new test case that is being added, so it is also fixed.
Differential Revision: D14876266
fbshipit-source-id: fe5b6bffd196d3bd74e7582e29484969495eac8e
Summary:
The command is supposed to check if the given commits are backed up and if not to back them up.
This is needed for `jf submit` to make sure that all the commits submitted are backed up by hg.
Reviewed By: markbt
Differential Revision: D14685222
fbshipit-source-id: 224a438ec1c5c17af6988c511be4af4a3a988a79
Summary:
If the cloud sync or pushbackup commands start in background themselves, it will trigger a new background command to back up to the secondary afterwards.
Note that for cloud sync, for the secondary store we trigger pushbackup command, not cloud sync. If should be fine. We don't backup duplicates as we always check with the server first what is already backup. To call pushback looks simpler as it doesn't involve all the complexity of cloud sync, and basically we just need to backup to the secondary.
Reviewed By: markbt
Differential Revision: D14578770
fbshipit-source-id: f81a50fd76e64f2d77d8d7004b201fcfe8a090d2
Summary: Deprecate due to complexity of the code.
Reviewed By: mitrandir77
Differential Revision: D14561405
fbshipit-source-id: 6184317f549c0ab84335b09c4b48efccdf31f7fc
Summary:
Basically we should check that the commits have been backed up.
If this is not true and the commits are local we can just back them up.
If they are not known by this repo, pull from the old one and then back them
up.
Reviewed By: markbt
Differential Revision: D14508239
fbshipit-source-id: 3fdd83335cb937b153510ec3c7510ecd1167d0ca
Summary:
Improve the performance of the revsets that calculate which commits to back up
by limiting them to consider only the non-obsolete commits that are also draft.
Reviewed By: quark-zju
Differential Revision: D14544883
fbshipit-source-id: db9ed4a7abd81956762f56140321242dbccf2df0
Summary:
Attempt to detect oscillation of commit cloud workspaces by comparing the new
state after the current sync with the state before the previous application of
cloud changes. If the version number is incremented by 1, the workspace is
brought back to the same state, and less than a minute has passed since the
last time that commit cloud sync ran, abort the current sync step.
This happens after the commits have been backed up, but before the new cloud
workspace is synced to the commit cloud service. This prevents further
oscillation whilst ensuring the user's commits are still backed up.
Reviewed By: quark-zju
Differential Revision: D14540355
fbshipit-source-id: 20e4b0333f5a7e34b512967a03099625f62ff9d5
Summary:
Change how commit cloud determines what to sync and what has been successfully
synced when some commits fail to push.
Commits to sync are all draft ancestors of non-obsolete commits, *plus* all
draft ancestors of bookmarked commits.
Commits to sync when only some commits have successfully been pushed are
ancestors of the newly pushed heads, *plus* ancestors of the commits to be
synced that were successfully synced last time.
Reviewed By: liubov-dmitrieva
Differential Revision: D14540357
fbshipit-source-id: c082a2f2822f8bce4cd2bbac93a70e27e2ffaa59
Summary: This is removal of unused code that left from D14455360
Reviewed By: ikostia
Differential Revision: D14502837
fbshipit-source-id: df1912c7997847b0628b492b3fe735d5e3d7f201
Summary:
In preparation to support Mononoke clean up the features that are Mercurial
specific and Mercurial infinitepush implementation specific.
For Mononoke migration we will to write a whole new set of logic what to do if
the "infinitepush" path has been changed. So, clean up is useful before
writing this logic.
Reviewed By: singhsrb
Differential Revision: D14455360
fbshipit-source-id: d15c3a9032b4888a1aa391da34ad5e499aba9a15
Summary:
D14183009 made commit cloud accept cloud bookmarks for hidden commits, rather
that omitting them. However, this only works for future bookmarks. If the
bookmark was already omitted, then `_checkomissions` would not recover the
situation for the same reason.
Update `_checkomissions` to also allow cloud bookmarks on hidden commits.
Reviewed By: liubov-dmitrieva
Differential Revision: D14437656
fbshipit-source-id: 2372323022a59bfd4210bc76f39b9a74872d5efe
Summary:
For pushbackup it is needed to make hg rage more informative because we store
states for different paths separately anyway.
For cloud sync we will have to write some migration logic: if the remotepath
has been changed, we have to check what the server has to make sure everything
is backed up as cloud sync would expect.
Differential Revision: D14420713
fbshipit-source-id: 2046e9d7b16291a49d1bc40da5285de58017f4f2
Summary:
When commits are added or modified, update the set of visible heads if
visibility tracking is enabled.
Reviewed By: DurhamG
Differential Revision: D12980779
fbshipit-source-id: 8f44045159c86a374ae530fa4327ee0807b4320d
Summary: just provide the important information
Reviewed By: quark-zju
Differential Revision: D14230573
fbshipit-source-id: 945bb0be48ed38ba4511d0cef605ef0b7baa2b5d
Summary:
When receiving cloud bookmarks, if they point to a hidden/obsolete commit,
don't omit them. The bookmark will make the commit visible again.
Reviewed By: quark-zju
Differential Revision: D14183009
fbshipit-source-id: ddcb8cce6aaa1eefae93490f76c3dffeaffda21c
Summary:
add this check to avoid overhead
we don't need to backup to the secondary place if it is the same as the first.
Reviewed By: singhsrb
Differential Revision: D14187754
fbshipit-source-id: 6ee59ae2f0846716ca99253958af7088d0538df9
Summary:
We can't run in parallel at the moment as the log file and the lock file are
shared.
Every path maintains independent backup state (the previous diff).
The secondary backup state doesn't affect smartlog (only the main one)
The issue with this approach is that we maintain backup lock a bit longer.
Unfortunately, the progress in smartlog doesn't show anything about the second backup.
I added 'finished', it makes it easier to compare in the logs.
Reviewed By: markbt
Differential Revision: D14149399
fbshipit-source-id: f90e8aac6cb8dee53d5c7468bd6adba067e13362
Summary:
We are going to support 2 different backends of Commit Cloud: Mercurial and
Mononoke.
Each of them should maintain local backup state separately.
Output of some tests have been slightly changes, this is because a separate backup
state, the same error appears earlier when we are trying the backup stacks.
The idea is to have separate backup states for different remote paths, but
there will be only one cloud sync state for the current source of
truth. We could include there the remote path and then validate that cloud sync
state is correct if the remote path has been changed.
However, for backup states it is much easier to have them separately (and we
will backup in 2 places)
Reviewed By: markbt
Differential Revision: D14138496
fbshipit-source-id: 0a7a763a395be5456cbd724bff7ebc069f03fb0e
Summary:
Prepare the code to use 'known' wireprotocol command to check what is backed up
on the server instead of slower 'lookup'. We don't need to reestablish ssh
connection, and we can test all the nodes in one go.
Also test the 'known' request with Mononoke is working (all commands have been
tested with isbackedupnodes => isbackedupnodes2)
Reviewed By: markbt
Differential Revision: D14131383
fbshipit-source-id: 5a150b64d0e84a02357c2367879b2da8493d9167
Summary:
Use the same way to check if the commits have been backed up in Mononoke and Mercurial.
The only common way to check is 'lookup' command because Mercurial doesn't support discovery for commit cloud commits, the command 'known' is also not supported.
Also we have to go one by one because lookup doesn't got any better API.
It is still much faster than backup commits that are already there.
Introduce such check for pushbackup as well.
Remove hacky way to check it from cloud sync.
For commit cloud in Mononoke we will have backfill, so the server side check will be heavily used when you go to Mononoke at the first time.
Unfortunately connection pool module in mercurial is not good enough in detecting closed connections and can easily return a broken connection on the next call.
Reviewed By: markbt
Differential Revision: D14085849
fbshipit-source-id: d76d9a71f9efdbdfec4de3198cd428b6b693418d
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
