Summary:
This will be used to preserve the `--hidden` behavior by using a more complete
list of heads.
A test introduced by 6563438219
was removed as it does not make sense to me to force changing read size from 65536 to 1.
That commit itself does not have useful commit message, and I cannot find email review thread for it.
Reviewed By: sfilipco
Differential Revision: D17264382
fbshipit-source-id: cc17e98eef4a4743e5207795a7054db59aa71fc0
Summary:
The inline revlog format merges `.i` and `.d` into one `.i` file. It was intended to reduce the
number of files for filelogs. For the changelog one extra file does not hurt.
This makes it easier to write native code parsing the changelog revlog index.
Reviewed By: xavierd
Differential Revision: D17125922
fbshipit-source-id: f48ffe0d2df71abec007a80e05b684dcbac71883
Summary:
Add a `mercurial.blackbox` module which just delegates to the Rust
binding. This means blackbox is no longer optional.
Change `ui.log` to log to the native blackbox as `LegacyLog` event.
The plan is to slowly migrate users from `ui.log` to `blackbox.log`,
which supports well-defined event types (instead of `LegacyLog`).
This does not change the `blackbox` command, which still uses the
legacy blackbox implementation. That will be changed in a later diff.
Reviewed By: markbt
Differential Revision: D15640720
fbshipit-source-id: de171f46e1430060083c9b7aee0a96dde315d021
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:
When the user checks out a new commit (either by updating to it, by
creating a new commit, or by amending or rebasing the current commit), create a
unique identifier for that checkout.
Log this identifier at the start and end of command processing, and allow other
tools to also query and log the identifier.
This allows both Mercurial commands and other commands that log the identifier
to be correlated with a particular checkout.
Reviewed By: quark-zju
Differential Revision: D14648523
fbshipit-source-id: 2fad79c3010f5fad1a0e180e3d3d6d9c0a7f8e85
Summary:
This hardcodes several perftweaks configs that have been enabled for major FB
repos for months:
[perftweaks]
disablebranchcache = True
disablebranchcache2 = True
disableresolvingbranches = True
disableupdatebranchcacheoncommit = True
Practically, this means the branchmap is now just `{'default': heads}`. (i.e.
there are no named branches other than `default`), and branchcache is removed
(i.e. `.hg/cache` does not exist without clindex or in-repo tags).
This diff only makes easy-to-verify logic changes by assuming the configs and
removing dead code. Things can be further cleaned up. They will be done by
upcoming changes.
Most test changes are due to the fact that `.hg/cache` is no longer created.
Reviewed By: singhsrb
Differential Revision: D14179858
fbshipit-source-id: 479f7427168eb1d9614a973e273a229e50f5620a
Summary:
Add the `storerequirements` feature to the repo. This means the store may have
a `requires` file, and clients must check it for any store features that they
may be missing. This allows new requirements to be added that affect the store
when the repo is shared. Currently there are no store features.
This commit adds support for the feature, and only new repos have the
requirement added. A future commit will optimistically upgrade repos to
include the requirement.
Reviewed By: quark-zju
Differential Revision: D9699156
fbshipit-source-id: 95c1ab6973d44c02abc69b78a15311fe6a8696fd
Summary:
Enable it by default so all tests run with it.
The test changes are mostly caused by repo requirement changes.
Reviewed By: DurhamG
Differential Revision: D8880991
fbshipit-source-id: f96cecfd85b8088098c3b55d06ab0374ee93437b
Summary: Run tests with watchman built from fbcode master. So we get signals about watchman/hg changes.
Reviewed By: DurhamG
Differential Revision: D8448187
fbshipit-source-id: 8643f139932057f326bc75b0b0c5cc616355eeed
Summary:
Previously it is not actually used.
`test-hgext-repogenerator.t` changed because treedirstate uses random
number to generate file names.
`fakedirstatewritetime.py` was updated to be treedirstate-aware. This
makes test-revert.t test-merge-tools.t test-merge1.t pass.
Reviewed By: singhsrb
Differential Revision: D7844960
fbshipit-source-id: 33a1d0d4a8e22ea5e6bb6454956884571fcf6bab
Now that we garantee that branchmap cache is updated at the end of the
transaction we can drop this update. This removes a problematic case with
nested transaction where the new cache could be written on disk before the
transaction is finished (and even roll-backed)
Such premature cache write was visible in the following test:
* tests/test-acl.t
* tests/test-rebase-conflicts.t
In addition, running the cache update later means having more date about the
state of the repository (in particular: phases). So we can generate caches with
more information. This creates harmless changes to the following tests:
* tests/test-hardlinks-whitelisted.t
* tests/test-hardlinks.t
* tests/test-phases.t
* tests/test-tags.t
* tests/test-inherit-mode.t
This is one step towards having dirstate manage its own storage. It will
be useful for the implementation of sql dirstate [1].
This introduced a small test change: now we always write the dirstate before
saving backup so in some cases where dirstate file didn't exist yet
savebackup can create it.
[1] https://www.mercurial-scm.org/wiki/SQLDirstatePlan
Before this patch, making a commit on a local repo could move a bookmark and
both operations would not be grouped as one transaction. This patch makes both
operations part of one transaction. This is necessary to switch to the new api
to save bookmarks repo._bookmarks.recordchange if we don't want to change the
current behavior of rollback.
Dirstate change happening after the commit is done is now part of the
transaction mentioned above. This leads to a change in the expected output of
several tests.
The change to test-fncache happens because both lock are now released in the
same finally clause. The lock release is made explicitly buggy in this test.
Previously releasing lock would crash triggering release of wlock that crashes
too. Now lock release crash does not directly result in the release of wlock.
Instead wlock is released at garbage collection time and the error raised at
that time "confuses" python.
Once the transaction is closed, we now write transaction related data for
possible future undo. For now, we only do it for full file "backup" because
their were not handle at all in that case. In the future, we could move all the
current logic to set undo up (that currently exists in localrepository) inside
transaction itself, but it is not strictly requires to solve the current
situation.
The revbranchcache is read on demand before it will be used for updating the
branch map. It is written back when the branchmap is written and it will thus
use the same locking as branchmap. The revbranchcache instance is short-lived;
it is only stored in the branchmap from .update() is invoked and until .write()
is invoked. Branchmap already assume that the repo is locked in that case.
The use of revbranchcache for branch map updates will make sure that the
revbranchcache "always" is kept up-to-date.
The perfbranchmap benchmark is somewhat bogus, especially when we can see that
the caching makes a significant difference between the realistic case of a
first run and the rare case of rerunning it with a full cache. Here are some
'base' numbers on mozilla-central:
Before:
! wall 6.912745 comb 6.910000 user 6.840000 sys 0.070000 (best of 3)
After - initial, cache is empty:
! wall 7.792569 comb 7.790000 user 7.720000 sys 0.070000 (best of 3)
After - cache is full:
! wall 0.879688 comb 0.880000 user 0.870000 sys 0.010000 (best of 4)
The overhead when running with empty cache comes from checking, missing and
updating it every time.
Most of the performance improvement comes from not having to extract the branch
info from the changelog. The last doubling of performance comes from no longer
having to convert all branch names to local encoding but reuse the few already
converted branch names.
On the hg repo:
Before:
! wall 0.715703 comb 0.710000 user 0.710000 sys 0.000000 (best of 14)
After:
! wall 0.105489 comb 0.110000 user 0.110000 sys 0.000000 (best of 87)
The phase cache file is no longer written on lock release, it is now handled by
the transaction (as changesets and obsolescence markers are).
(Hooray)
As we stop relying on the lock to write phase, repos with no existing phase
information will need to wait for a phase move or a strip to happen in order to
get the first write in the `phaseroots` file. This explain the change in
test-inherit-mode.t.
This should not have any side effects but in very obscure cases where
people interact with pre-2.1 and post-2.1 versions of Mercurial on the
same repo while having MQ patches applied but the MQ extension
disabled from time to time. A case unlikely enough to not be worth
preserving the old behavior with awful hacks.
Now that changelog filtering is in place, it's become evident that
naming the filters according to the set of revs _not_ included in the
filtered changelog is confusing. This is especially evident in the
collaborative branch cache scheme.
This changes the names of the filters to reflect the revs that _are_
included:
hidden -> visible
unserved -> served
mutable -> immutable
impactable -> base
repoview.filteredrevs is renamed to filterrevs, so that callers read a
bit more sensibly, e.g.:
filterrevs('visible') # filter revs according to what's visible
The `mutable` filter still have some chance to get invalidated. This will happen
when:
- you garbage collect hidden changeset,
- public phase is moved backward,
- something is changed in the filtering (this could be fixed)
So we introduce an even more stable filtering set: everything with a revision
number egal or higher than the first mutable changeset is filtered.
The only official use of this filter is for branchcache.
It filters all mutable changesets, leaving only public changeset unfiltered.
This filtering set is expected to be much more stable that the previous one as
public changeset are unlikely to disapear.
The only official use of this filter is for branchcache.
Filtered repository are *subset* of unfiltered repository. This means that a
filtered branchmap could be use to compute the unfiltered version.
And filtered version happen to be subset of each other:
- "all() - unserved()" is a subset of "all() - hidden()"
- "all() - hidden()" is a subset of "all()"
This means that branchmap with "unfiltered" filter can be used as a base for
"hidden" branchmap that itself could be used as a base for unfiltered
branchmap.
unserved < hidden < None
This changeset implements this mechanism. If the on disk branchcache is not valid
we use the branchcache of the nearest subset as base instead of computing it from
scratch. Such fallback can be cascaded multiple time is necessary.
Note that both "hidden" and "unserved" set are a bit volatile. We will add more
stable filtering in next changesets.
This changeset enables collaboration between no filtering and "unserved"
filtering. Fixing performance regression introduced by 7bff5f37cb97
Some tests ended up in a directory several directories deeper than $TESTTMP,
usually because some 'cd ..' had been forgotten between different test cases.
Add 'cd ..' where they are missing so the tests get back where they started.
In freebsd, a newly created directory has the same group as the parent
directory by default. That means that the test directory created by
test-inherit-mode.t is owned by root's group, so "chmod g+s .hg/store"
fails to set the SGID bit and returns 1. If we ignore chmod's return
code, the testsuite passes again.
Marks phase data as dirty when computing default phase. Actual writing is done
when the lock is released. So, read only operation don't write phase data
because they don't lock the repo.
test-mq-cache.t did apparently look at stale cache content.
Testing with different locking mechanism happened to update the cache more
frequently and thus caused a test failure.
Before this patch undo.bookmarks was created on bookmarks write and
not with other transaction-related files. There were two issues: first
is that if you have changed bookmarks few times after a transaction
happened, rollback will give you a state which can point to
non-existing revision. Second is that if you have not changed
bookmarks after a transaction, rollback will touch your state anyway.
This change also adds `localrepo._writejournal` method, which can be
used by other extensions to save their transaction-related backup in
right time.
The generation of cache files like tags.cache and branchheads.cache is not an
actual reflection of things changing in the whole of the .hg directory (like eg
a commit or a rebase or something) but instead these cache files are just part
of bookkeeping. As such its convienant to allow various clients to ignore file
events to do with these cache files which would otherwise cause a double
refresh. Eg one refresh might occur after a commit, but the act of refreshing
after the commit would cause Mercurial to generate a new branchheads.cache which
would then cause a second refresh, for clients.
However if these cache files are moved into a directory like eg .hg/cache/ then
GUI clients on OSX (and possibly other platforms) can happily ignore file events
in this cache directory.
