- Jun 20, 2017
-
-
Augie Fackler authored
Spotted one of these, then wrote a check-code rule that caught them all. It will be the next change.
-
- May 02, 2017
-
-
Pierre-Yves David authored
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
-
- May 11, 2016
-
-
Mateusz Kwapich authored
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
-
- Nov 18, 2015
-
-
Laurent Charignon authored
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.
-
- Jan 17, 2015
-
-
Pierre-Yves David authored
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.
-
- Jan 07, 2015
-
-
Mads Kiilerich authored
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)
-
- Aug 07, 2014
-
-
Pierre-Yves David authored
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.
-
- Aug 06, 2014
-
-
Matt Mackall authored
-
- Sep 16, 2013
-
-
Brodie Rao authored
This lets us determine the open/closed state of a branch without reading from the changelog (which can be costly over NFS and/or with many branches).
-
- Jan 13, 2013
-
-
Kevin Bullock authored
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
-
- Jan 02, 2013
-
-
Pierre-Yves David authored
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.
-
Pierre-Yves David authored
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.
-
- Jan 07, 2013
-
-
Pierre-Yves David authored
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 47f00b0de337
-
- Jun 10, 2012
-
-
kiilerix authored
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.
-
- Mar 01, 2012
-
-
Javi Merino authored
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.
-
- Jan 30, 2012
-
-
Pierre-Yves David authored
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.
-
- Jan 13, 2012
-
-
kiilerix authored
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.
-
- Nov 10, 2011
-
-
Pierre-Yves David authored
-
- Nov 07, 2011
-
-
Pierre-Yves David authored
-
- May 01, 2011
-
-
Alexander Solovyov authored
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.
-
- Jan 04, 2011
-
-
jfh authored
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.
-
- Oct 16, 2010
-
-
Adrian Buehlmann authored
and fix the offending tests accordingly
-
- Aug 30, 2010
-
-
Nicolas Dumazet authored
-
- Mar 18, 2008
-
-
Alexis S. L. Carvalho authored
If we don't change any rwx bit in the last test, hg will skip the calls to chmod since it'll assume they're not needed. This might fix things on BSD systems.
-
- Feb 21, 2008
-
-
Alexis S. L. Carvalho authored
-
- Feb 15, 2008
-
-
Alexis S. L. Carvalho authored
HFS+ doesn't like setgid directories, so avoid them in most of the test and do a quick check that doesn't change the output when everything's OK.
-
- Feb 10, 2008
-
-
Thomas Arendsen Hein authored
-
- Feb 09, 2008
-
-
Alexis S. L. Carvalho authored
-
Alexis S. L. Carvalho authored
-