Wed, 25 Mar 2015 13:55:32 +0900 subrepo: add dirtyreason to centralize composing dirty reason message
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 25 Mar 2015 13:55:32 +0900] rev 24470
subrepo: add dirtyreason to centralize composing dirty reason message This patch newly adds "dirtyreason()" to centralize composing dirty reason message like "uncommitted changes in subrepository 'xxxx'". There are 3 similar messages below, and this patch is a part of preparations for unifying them into (1), too. 1. uncommitted changes in subrepository 'XXXX' 2. uncommitted changes in subrepository XXXX 3. uncommitted changes in subrepo XXXX This patch chooses adding new method "dirtyreason()" instead of making "dirty()" return "reason string", because: - some of existing "dirty()" implementation is too complicated to do so simply, and - ill-mannered 3rd party subrepo classes, of which "dirty()" doesn't return "reason string", cause meaningless message (even though it is rare case)
Wed, 25 Mar 2015 16:40:37 -0700 record_curses: add test for newly added files
Laurent Charignon <lcharignon@fb.com> [Wed, 25 Mar 2015 16:40:37 -0700] rev 24469
record_curses: add test for newly added files We have a UI bug where toggling a newly added file twice in the curses interface didn't mark it as selected. This test checks that the underlying logic is working as expected, the next patch of the series fixes the UI bug.
Wed, 25 Mar 2015 17:18:48 -0700 test-manifest.py: don't test .text() with present node suffix
Martin von Zweigbergk <martinvonz@google.com> [Wed, 25 Mar 2015 17:18:48 -0700] rev 24468
test-manifest.py: don't test .text() with present node suffix When m.text() is called after setting a nodeid with a suffix (such as '+'), manifestdict uses the suffix-less nodeid for the text, while treemanifest includes the suffix. It would perhaps make most sense to raise an exception so the bug is found, but since the two implementations behave differently, let's just not test the behavior for now.
Thu, 26 Mar 2015 09:42:21 -0700 treemanifest: drop 22nd byte for consistency with manifestdict
Martin von Zweigbergk <martinvonz@google.com> [Thu, 26 Mar 2015 09:42:21 -0700] rev 24467
treemanifest: drop 22nd byte for consistency with manifestdict When assigning a 22-byte hash to a nodeid in a manifest, manifestdict drops the 22nd byte, while treemanifest keeps it. Let's make treemanifest drop the 22nd byte as well.
Wed, 25 Mar 2015 14:13:46 -0700 test-manifest.py: rewrite tests in terms of manifestdict
Martin von Zweigbergk <martinvonz@google.com> [Wed, 25 Mar 2015 14:13:46 -0700] rev 24466
test-manifest.py: rewrite tests in terms of manifestdict By rewriting test-manifest.py in terms of manifestdict instead of _lazymanifest, the tests can be run on treemanifests too. There are still a few tests that fail on treemanifests. They will be addressed in the next few patches.
Wed, 25 Mar 2015 14:21:34 -0700 test-manifest.py: separate out test for double-free after copy()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 25 Mar 2015 14:21:34 -0700] rev 24465
test-manifest.py: separate out test for double-free after copy() The test that we don't double-free anything after creating a copy is currently mixed with the __setitem__ test. Let's separate them.
Wed, 25 Mar 2015 22:20:44 -0400 revert: evaluate subrepos to revert against the working directory
Matt Harbison <matt_harbison@yahoo.com> [Wed, 25 Mar 2015 22:20:44 -0400] rev 24464
revert: evaluate subrepos to revert against the working directory Reverting to a revision where the subrepo didn't exist will now abort, and matching subrepos against the working directory is consistent with how filesets are evaluated since 5b85a5bc5bbb.
Wed, 25 Mar 2015 21:54:47 -0400 revert: handle subrepos missing in the given --rev
Matt Harbison <matt_harbison@yahoo.com> [Wed, 25 Mar 2015 21:54:47 -0400] rev 24463
revert: handle subrepos missing in the given --rev The list of subrepos to revert is currently based on the given --rev, so there is currently no way for this to fail. Using the --rev context is wrong though, because if the subrepo doesn't exist in --rev, it is skipped, so it won't be changed. This change makes it so that the revert aborts, which is what happens if a plain file is reverted to -1. Finding matches based on --rev is also inconsistent with evaluating files against the working directory (5b85a5bc5bbb). This change is made now, so as to not cause breakage when the context is switched in an upcoming patch.
Wed, 25 Mar 2015 16:21:58 -0700 osutil: mark end of string with null char, not 0
Siddharth Agarwal <sid0@fb.com> [Wed, 25 Mar 2015 16:21:58 -0700] rev 24462
osutil: mark end of string with null char, not 0 Noticed this while working on other stuff in the area.
Wed, 25 Mar 2015 15:55:31 -0700 osutil: use getdirentriesattr on OS X if possible
Siddharth Agarwal <sid0@fb.com> [Wed, 25 Mar 2015 15:55:31 -0700] rev 24461
osutil: use getdirentriesattr on OS X if possible This is a significant win for large repositories on OS X, especially with a cold cache. Unfortunately we need to keep the lstat-based implementation around for two reasons: - Not all filesystems support this call. - There's an edge case in which it's best to fall back to avoid a retry loop. More about this in the comments. The below tests are all performed on a Mac with an SSD running OS X 10.9, on a repository with over 200k files. The results are best of 5 with simulated best-effort conditions. The gains with a hot cache are pretty impressive: 'hg status' goes from 5.18 seconds to 3.79 seconds. However, a repository that large will probably already be using something like hgwatchman [1], which helps much more (for this repo, 'hg status' with hgwatchman is approximately 1 second). Where this really helps is when the cache is cold [2]: hg status goes from 31.0 seconds to 9.66. See http://lists.apple.com/archives/filesystem-dev/2014/Dec/msg00002.html for some more discussion about this function. This is based on a patch by Sean Farley <sean@farley.io>. [1] https://bitbucket.org/facebook/hgwatchman [2] There appears to be no easy way to clear the file cache (aka "vnodes") on OS X short of rebooting. purge(8) purportedly does that but in my testing had little effect. The workaround I came up with was to assume that vnode eviction was LRU, make sure the kern.maxvnodes sysctl is smaller than the size of the repository, then make sure we'd always miss the cache by running 'hg status' in another clone of the repository before running it in the test repository.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip