Summary:
This test is broken right now because it requires the configuration
`treemanifest.server=True` on the test server repository. This commit fixes the
test by adding the requisite configuration.
Reviewed By: quark-zju
Differential Revision: D15528016
fbshipit-source-id: 2e10986959f59646dfb30ebc2637f08a64b6fa01
Summary:
The exact commit that base trees are found by can be non-deterministic. Allow
any commit to match in the tests.
Reviewed By: ikostia
Differential Revision: D15516337
fbshipit-source-id: 824ee33a595b86b1261d771ac4597fca7a9a8a9f
Summary:
In the next diff we enable Mononoke support for any test using the new
newserver and clone helpers. Mononoke only supports lz4revlog, so we need to
make sure newserver also creates lz4revlog repos.
Reviewed By: quark-zju
Differential Revision: D15382715
fbshipit-source-id: 21da5a3ad14947b87cf09771c723f2109e028da1
Summary:
In a future diff we'll convert this test to work with Mononoke. In
order to do so, we need it to not run hg client commands inside the server repo.
Let's update the test to instead populate the server repo via push. This also
makes it use bookmarks, which will be required by Mononoke.
Reviewed By: quark-zju
Differential Revision: D15382422
fbshipit-source-id: 2ed9dd0072cd02a3cb8bb0d7b31551bc35b30ba9
Summary:
Mercurial is maintaining it's own dummyssh, and they've started to
diverge. I've copied over the hgcli bits to Mercurial's dummyssh in order to
support Mononoke integration tests, so let's just symlink Mononoke to use
Mercurial's dummyssh.
Reviewed By: markbt
Differential Revision: D15382377
fbshipit-source-id: 0847ce6efac7db256f16cc53705777cf55f71593
Summary:
In a future diff we'll be adding support for running tests with
mononoke integration enabled. Initially it will be a small set of tests, so
having whitelist support will make this easier.
Reviewed By: markbt
Differential Revision: D15382019
fbshipit-source-id: ca9faa8ccecbcb8a10c691131c56784a166ea5c9
Summary:
When using the new server and client helpers, let's set some default
configuration that is expected in production. This will allow us to
mostly-transparently swap out the server with Mononoke for any test who uses
these helpers.
Reviewed By: quark-zju
Differential Revision: D15381856
fbshipit-source-id: 054fcc2768eba38e704e713aeb1bc8e84faa2be1
Summary:
This is a proof of concept test to show how we might convert tests to
use treeonly. A future iteration of this should show how we can insert mononoke
as the backend for the tests.
Reviewed By: quark-zju
Differential Revision: D15382163
fbshipit-source-id: e9c8af871260435f81ef9dbf6f20257b1ff2a35f
Summary:
Now that all our repos are treemanifest, let's enable the extension by
default in tests. Once we're certain no one needs it in production we'll also
make it the default in core Mercurial.
This diff includes a minor fix in treemanifest to be aware of always-enabled
extensions. It won't matter until we actually add treemanifest to the list of
default enabled extensions, but I caught this while testing things.
Reviewed By: ikostia
Differential Revision: D15030253
fbshipit-source-id: d8361f915928b6ad90665e6ed330c1df5c8d8d86
Summary:
Cloud sync backs up commits before it takes the lock. If, during this backup
process, another transaction adds new commits to the repository, the cloud sync
process will not be able to sync properly, as some of the commits won't have
been backed up.
Furthermore, because the backup state may have been updated between opening the
changelog and reading the backup state, which means the backup state may
reference commits that are not available in the changelog to the current
process.
Serialize these operations by:
* Reading the backup state file under the repo lock. This, unfortunately, means
`hg cloud backup` needs to take the lock, but it should only be for a very
brief period while a file is read.
* When cloud sync has completed the backup and is about to start syncing, check
that the repository hasn't changed while the backup was running. If it has,
abandon this sync attempt. Another background sync will have been scheduled
that will backup the new commits and then sync everything.
Reviewed By: quark-zju
Differential Revision: D15468485
fbshipit-source-id: 706ada05dfb1f539638104722a044493c7e3e62f
Summary:
If the visibility state file is read after the changelog is opened, the visibleheads
may have been modified to point to a commit that had been added to the changelog
afterwards, which means the commit is not accessible to the current process.
We need to ensure that the visibleheads file is read just before the changelog is
opened. The safest way to handle this is to make the visibleheads tracking part
of the changelog object. Whenever we open the changelog, we get a correctly
up-to-date view of the visible heads.
Reviewed By: quark-zju
Differential Revision: D15468483
fbshipit-source-id: 94d6b3e6db5211d7346f4a244f182383970fcb74
Summary:
Ensure cloud sync gets a consistent view of the repository, and that the sync
operation is a single update, by taking in the lock and using a transaction for
the whole cloud sync.
The commits are backed up before we take the lock, so for syncs that don't pull
in any new commits, this should still be relatively fast: we will only have the
lock for the duration of the request to the commit cloud service. In the case
that we do need to pull new commits, we were already taking the lock anyway.
Reviewed By: quark-zju
Differential Revision: D15468487
fbshipit-source-id: 37abeac85dad8d2cfb4ad160c5f417dde087d74c
Summary:
If a ui object is not available, then callers can't make blackbox logs. However,
the blackbox extension has `lastui()` which lets it find a ui object.
Add `util.log`, a hook point for blackbox that lets callers log to blackbox without
having a ui object to hand.
Reviewed By: quark-zju
Differential Revision: D15495215
fbshipit-source-id: b468647ccacc6992f71b9a8be2552db860d16ebe
Summary:
This extention will return 0 if the bookmark points to an expected hash and
non-0 otherwise. We plan to use it in Mononoke.
Reviewed By: StanislavGlebik
Differential Revision: D15450801
fbshipit-source-id: 36d938fb6912046ada229a4e35b76e9cf13f0a74
Summary:
Recently, the merge tools configs were moved from a file to a Rust
string. The path to these configs being empty, this caused the
stripping of '\\?\' on Windows to crash. Let's simply use "<builtin>"
in the `hg config --debug` output to signify an embedded config.
Reviewed By: quark-zju
Differential Revision: D15499196
fbshipit-source-id: 1141cfafde5ceae9c814ed711e00d93a4665c5fb
Summary:
Now that all our repos are treeonly, let's default the extension to
using treeonly. This opens the doors for moving all the tests to operating on
treeonly repos in a future diff.
Reviewed By: quark-zju
Differential Revision: D15030251
fbshipit-source-id: cd289775174bbacd6a6cdc7a5b07fe7e41238584
Summary:
Reading filectx info tried to use an optimization to get the filenode
without uncompressing the whole manifest. In a tree world, this optimization
actually hurts performance because it requires downloading the parent tree and
performing a diff. Since everything is now treeonly, let's just drop this
optimization.
This helps in some Eden tests where they prefetch a specific commit then attempt
to access it offline.
Reviewed By: markbt
Differential Revision: D15344433
fbshipit-source-id: 3b6ebc27ce7e263abefaa962856a4c7bea0df793
Summary:
Previously readfast was an optimization that sometimes returned a delta
against p1, but other times returned the full manifest. This was weird and
caused certain algorithms to sometimes be O(changes) but other times O(repo).
In a tree world we no longer need this optimization, so let's drop it.
readdelta is similar in that it would read the difference between a manifest and
it's delta base. This has no relationship to the delta between a manifest and
it's parent, so it's weird and we should get rid of it.
There is a legitimate use case for wanting to know what entries are new in a
manifest, like when deciding what to send over the wire. So let's add a new
readnew() function that is explicitly for reading what entries were introduced
by this tree. The implementation is basically the same as readdelta, but
deltaing against p1 instead of the deltabase.
Reviewed By: markbt
Differential Revision: D15344434
fbshipit-source-id: dc8dca326f66b2fc55cc76f93c7ce48aa7efedf3
Summary:
This makes it easier for a wrapping job to associate output with a given command it ran.
Note that creating a SSH peer creates its own copy of the `ui` object, which is why we have to push a buffer to both `ui` instances.
Reviewed By: ikostia
Differential Revision: D15468456
fbshipit-source-id: c6f1937749447e27332801577538d9874eb18898
Summary:
The phases command had some naive code that looped over every revision
in the repository. Twice. This was really slow on huge repos, so let's get rid
of the need for it.
I originally attempted to optimize it by only looking at commits greater than
the ones being passed in, but this is incorrect since changing a commit to
public may affect it's ancestors. Instead of trying to optimize it further,
let's just drop the output text entirely.
Reviewed By: quark-zju
Differential Revision: D15465942
fbshipit-source-id: ba63a1096a515032fe13a8699807fe69c73c80ed
Summary:
Previously we sorted the trees topologically before inserting them. On
a revlog-backed server, this may mean that trees are written in a different
order from the actual commits. hgsql-backed servers rely on the data being
written in linkrev order so they can be replayed in linkrev order on other
machines, so this broke hgsql replication.
Let's instead sort by linkrev, which will be both topological and satisfy
hgsql's requirements.
Reviewed By: quark-zju
Differential Revision: D15437953
fbshipit-source-id: d4aaaa03b392a6cb6cf1be478aed2583ecb757c5
Summary:
hgsql relies on all revisions being inserted in linkrev order.
Treemanifest was sorting topologically instead of by linkrev, which resulted in
possible corruption in hgsql backed servers. Let's add a test showing this.
Reviewed By: quark-zju
Differential Revision: D15437952
fbshipit-source-id: 642708d7bf76a0d0843a13f8c23b99108f05444a
Summary:
We had this disabled in a config we ship in rpms, but if we want the
tests to work in treeonly mode we want this disabled in all tree cases.
Reviewed By: xavierd
Differential Revision: D15296199
fbshipit-source-id: 0f9751583eefa10c275bd499bb5998adfbe644a4
Summary:
With treemanifest we no longer have manifest rev numbers, so let's drop
them from the templates. This let's us convert a few more tests to treeonly.
In theory automation may parse this, but I kinda doubt anyone parses the
manifest node from this.
Reviewed By: xavierd
Differential Revision: D15296141
fbshipit-source-id: a4d2194bd9604867cd9958509bcd2e6513a72494
Summary:
The test-hgsubversion-externals.py test contained string literals with significant trailing whitespace that was stripped by an editor in D15392154.
Restore the significant whitespace, and switch from multi-line string literals to a single string literal per line, to make the newlines and whitespace more obvious.
Reviewed By: krallin
Differential Revision: D15448869
fbshipit-source-id: 68444d2a31b71ab9f99927c95174a0d49e26bb06
Summary:
When syncing, if a locally-available bookmark is synced to a new commit that
has been omitted, remove the local bookmark to ensure that the next cloud sync
doesn't move the bookmark back to where it used to be.
Reviewed By: mitrandir77
Differential Revision: D15414172
fbshipit-source-id: 71aaa2d89f734e4c575c24da2c0ef6b59ca4deaa
Summary:
Add a test that shows moving a synced bookmark onto a commit which will be
omitted elsewhere causes the bookmark to be moved back.
Reviewed By: mitrandir77
Differential Revision: D15414173
fbshipit-source-id: 92dc42d1c5560fa2f5bc618d5335e21ac14d9e7d
Summary:
This hook fires for every commit that is introduced in a pull. When
doing pulls with hundreds of thousands of commits, this introduces a noticable
delay. We don't use this hook anywhere, and it's not particularly scalable, so
let's delete it.
Reviewed By: singhsrb
Differential Revision: D15424697
fbshipit-source-id: 98d76bca703e625adf5be8f6234436befd260fc4
Summary:
Let's move hgsubversion to absolute_import, just to be consistent with the rest
of Mercurial codebase.
Reviewed By: markbt
Differential Revision: D15392154
fbshipit-source-id: e4c32939aff0616790828da508f3feea158669e1
Summary:
The postincoming checks prints out advice of the following forms:
* `(run 'hg heads' to see heads)`
* `(run 'hg heads' to see heads, 'hg merge' to merge)`
* `(run 'hg heads .' to see heads, 'hg merge' to merge)`
* `(run 'hg update' to get a working copy)`
This advice is no longer useful, so remove it.
Reviewed By: DurhamG, farnz
Differential Revision: D15317185
fbshipit-source-id: 50ba576406c96715fa058399da53462be9b7a3bf
Summary:
Improve logging of background backup commands by including the command that was
run and the time it was started in the background backup logs.
Reviewed By: mitrandir77
Differential Revision: D15334879
fbshipit-source-id: 932e91a43033c5cb06c79ede7b5224da2e34eb7d
Summary:
When pulling heads from commit cloud during sync, pull them in small groups
of heads from around the same time, to prevent overloading the server when
pulling a large number of heads.
Reviewed By: mitrandir77
Differential Revision: D15317184
fbshipit-source-id: 5e69eb970b18292a4f5d643b25fac80c90c5d537
Summary:
Refactor how commit cloud sync works.
Sync is simplified by delegating backup processing to the existing backup code.
This happens first, which means the user's work is backed up earlier, and the
sync processing can assume that all backed up commits are available in the
cloud storage.
Sync no longer attempts to handle the case where cloud storage has changed.
Instead, backup processing should ensure that all local commits are backed up
to the current cloud storage.
If a commit can't be backed up, then treat this as a normal failure to
sync and ignore that commit for this sync attempt. If a commit can't be
downloaded from the server then the sync fails.
Reviewed By: mitrandir77
Differential Revision: D15295499
fbshipit-source-id: d371c5bf0daedbbe42e8c7d4a0c3d1a40c21a36f
Summary:
If the user has a bookmark pointing at an obsolete commit, and then moves that
bookmark away from that commit, commit cloud can't tell whether the commit
should really be obsolete or not. Previously the bookmark was the only thing
keeping the commit visible, but commit cloud doesn't know that.
I can't think of a way to fix this with obsmarkers. It works with separate
mutation and visibility (T34204947).
Reviewed By: quark-zju
Differential Revision: D15097845
fbshipit-source-id: 5926553b4878b28823a6ce47d29c0346cba04e5e
Summary:
Merge the functionality of the infinitepushbackup extension (backing up commits
to commit cloud) into the commitcloud extension.
These two extensions are highly coupled, and the commitcloud extension
monkey-patches the infinitepushbackup extension for a lot of its functionality.
There is also a lot of code duplication between the two extensions which we can
remove if they are part of the same extension.
The infinitepushbackup commands (`hg pushbackup`, ...) are moved to subcommands
of the `hg cloud` command, e.g. `hg cloud backup`.
Each feature of the infinitepushbackup extension is moved to a new module
in the commit cloud extension:
The `background` module controls background execution of `hg cloud backup` and
`hg cloud sync`.
The `backupbookmarks` module tracks and updates scratch bookmarks for backups.
This will be deprecated in the future.
The `backupstate` module tracks whether or not a commit has been backed up.
This is now tracked separately from backup bookmarks in a new file:
`.hg/commitcloud/backedupheads.<remote-identifier>`. This also covers hidden
commits, preventing a re-backup of previously backed up commits when they are
unhidden.
Previously the commitcloud extension customized the smartlog annotations: `Backing up`
became `Syncing`, etc. This is now removed for consistency.
Previously the infinitepushbackup extension disabled background backup by
injecting an `infinitepushbackup.disableduntil` config entry into the user's
config. This is now replaced with a state file at `.hg/commitcloud/autobackup`.
Either option can be set to disable auto backup. Commit cloud will wait until
both have expired before starting to run background backups again.
Reviewed By: DurhamG
Differential Revision: D15276939
fbshipit-source-id: 1d28989a157286e47d3dd97ca9c70b27f692dda1
Summary:
D15381038 made the `pyrevisionstore` crate a strongly-coupled dependency of the
`bindings` crate. For simplicity, just move the code into the bindings crate.
Reviewed By: xavierd
Differential Revision: D15392547
fbshipit-source-id: 3dfa924b33722760ef7829fbb8659ce0262e6671
Summary:
This is a nice-to-have feature requested by nikz. He made an initial version
at D15029612, which changes `MatchResult` to include enough infomation to
explain a rule.
The diff reworked the feature so the runtime CPU and memory overhead stay
minimal if nothing needs to be explained. The change also makes it easier
to display more information - all rules matching a path, to make it easier
to detect and remove duplicated or conflicting rules.
Reviewed By: DurhamG
Differential Revision: D15095576
fbshipit-source-id: 5784aabd50d9b716dceead10bc593f9155228046
Summary:
After D15266191, the bindings crate directly depends on pyrevisionstore, and
since then we have seen really weird compilation errors that magically go away
when some files are touched.
From my observations, here is what I came up with. The pyrevisionstore crate is
both compiled as a dependency of the bindings crate, and as a library to be
used in python. Therefore, its Cargo.toml contains a '[lib]' section, the
presence of this section forces the crate to be compiled into a
"libpyrevisionstore.{rlib,so}", while all the regular crates have a hashed
suffix like "libedenapi-2b9975ec9b865e87.rlib".
None of this would usually matter, but our build system re-uses the build
directory to then compile the pyrevisionstore library. While doing so, it will
re-create the "libpyrevisionstore.{rlib,so}", but not in an identical fashion.
After this, the rest of the build succeeds.
Once a file in the bindings crate is touched, recompiling will only recompile
its file, and not the pyrevisionstore crate, but since
"libpyrevisionstore.{rlib,so}" is different, it now fails to compile...
A previous effort tried to compile each top level target into a separate
directory, but that directly affected some of our tests. Since the underlying
issue is that pyrevisionstore is compiled twice, let's simply not compile it as
a top-level target and simply fold it into the bindings lib. Ideally, we would
want to do the opposite, but let's do that at a later time.
Reviewed By: DurhamG
Differential Revision: D15381038
fbshipit-source-id: 047cfab794371464942f19084ffb9240e836cb40
Summary: When the `--shared` flag is passed to `hg root` i.e. `hg root --shared` - display the shared root of the current directory.
Reviewed By: quark-zju
Differential Revision: D15363157
fbshipit-source-id: 6e6c13f27c624502a83edc1046ae3d4de227b6b8
Summary:
See the previous diff (D15291676) for motivation. Basically, it's hard to keep
static resources work well with 3 different kinds of deployments (buck xar,
Windows zip, and python side-packages).
This diff just precomputes common styles and hardcoded them in Python code.
This should address a user complaint that `-T xml` does not work.
Reviewed By: markbt
Differential Revision: D15307457
fbshipit-source-id: de4edb0b6896b731301715abe612a31b1512b00a
Summary:
The `-` graphnode can be confusing as `-` is also used for horizontal graph lines.
There are no good ASCII characters to use for invisible commits, so revert to
just using `x` so that they match obsolete commits.
Reviewed By: quark-zju
Differential Revision: D15293717
fbshipit-source-id: 5d1f327ddd8c3f104a99f494309a79b10ad71401
Summary:
There are multiple reports that the work in the commit message editor gets lost
for various reasons. We have `.hg/last-message.txt` for commit hook failure,
but that one does not take care of all code paths (ex. metaedit).
This diff changes `ui.edit` directly to try to save messages in `.hg/edit-tmp`
for 2 weeks.
Reviewed By: kulshrax
Differential Revision: D15347831
fbshipit-source-id: 9207adf4315d94a4892685a03f323e89d9c4a7f1
Summary:
Clean up things:
- Build scripts. They are probably broke. We have different build scripts.
- hgk. Probably broken.
- docker. We won't maintain hgweb as-is.
- Utilities from fb-hgext. They are no longer used.
Reviewed By: kulshrax
Differential Revision: D15327228
fbshipit-source-id: 3568f20ddce6b364a46d306d95279b7faaef9f82
Summary: Make `hg debugignore` show what gitignore rules match the files.
Reviewed By: quark-zju
Differential Revision: D15029612
fbshipit-source-id: e3621c198b9d6e3823de5587b0b859d2d0e36888
Summary: As a follow-up of D15338757, remove the scripts around building doc/.
Reviewed By: singhsrb
Differential Revision: D15340829
fbshipit-source-id: bc121947696aaecd574edf3d9b9b3e874037bcda
Summary:
It's a headache about how to deal with static files (help/, template/, default
config), since we have 3 different ways of packing the Python code: normal
(linux), embedded (Windows), and fbcode xar (linux). The latter two need
workarounds to make `help/` work, and for the "embedded" case, It is currently
broken.
This diff moves user-facing `help/` files to a Python module to remove the need
of special casing it in different ways.
`helptext.py` was created via:
import glob, os
for path in glob.glob('help/*.txt'):
if path.count('.') == 1:
name = path.split('.')[0]
name = os.path.basename(name)
if '-' in name:
name = 'globals()[%r]' % name
print("%s = r'''%s'''\n\n" % (name, open(path, "rb").read()))
os.unlink(path)
The help text about named branches are removed to make `test-check-help.t`
happy.
Reviewed By: mitrandir77
Differential Revision: D15291676
fbshipit-source-id: 2320bd59369ef092d8c06b8539e401799a0467ef
