Sat, 01 Jul 2017 10:29:27 -0700 sparse: rename command to debugsparse
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 01 Jul 2017 10:29:27 -0700] rev 33293
sparse: rename command to debugsparse Sparse checkout is still highly experimental and not protected by BC guarantees yet. We also haven't had a discussion on the UX. To discourage use, we rename the sparse command to debugsparse.
Thu, 06 Jul 2017 10:54:23 -0700 sparse: remove reference to simplecache
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 06 Jul 2017 10:54:23 -0700] rev 33292
sparse: remove reference to simplecache This is a 3rd party extension authored by Facebook. References in core are not appropriate. It will be possible to restore this code/optimization via monkeypatching. So Facebook won't lose any functionality. The removed code is important for performance. So add a comment tracking it.
Sat, 01 Jul 2017 10:24:31 -0700 sparse: remove reference to hgwatchman
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 01 Jul 2017 10:24:31 -0700] rev 33291
sparse: remove reference to hgwatchman This is a legacy extension. Now that the extension is in core, we only need to support what's in core, which is fsmonitor.
Sat, 01 Jul 2017 10:36:03 -0700 sparse: expand module docstring
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 01 Jul 2017 10:36:03 -0700] rev 33290
sparse: expand module docstring Clarify lack of BC guarantees. And say a bit more about the extension.
Sat, 01 Jul 2017 10:43:29 -0700 sparse: vendor Facebook-developed extension
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 01 Jul 2017 10:43:29 -0700] rev 33289
sparse: vendor Facebook-developed extension Facebook has developed an extension to enable "sparse" checkouts - a working directory with a subset of files. This feature is a critical component in enabling repositories to scale to infinite number of files while retaining reasonable performance. It's worth noting that sparse checkout is only one possible solution to this problem: another is virtual filesystems that realize files on first access. But given that virtual filesystems may not be accessible to all users, sparse checkout is necessary as a fallback. Per mailing list discussion at https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095868.html we want to add sparse checkout to the Mercurial distribution via roughly the following mechanism: 1. Vendor extension as-is with minimal modifications (this patch) 2. Refactor extension so it is more clearly experimental and inline with Mercurial practices 3. Move code from extension into core where possible 4. Drop experimental labeling and/or move feature into core after sign-off from narrow clone feature owners This commit essentially copies the sparse extension and tests from revision 71e0a2aeca92a4078fe1b8c76e32c88ff1929737 of the https://bitbucket.org/facebook/hg-experimental repository. A list of modifications made as part of vendoring is as follows: * "EXPERIMENTAL" added to module docstring * Imports were changed to match Mercurial style conventions * "testedwith" value was updated to core Mercurial special value and comment boilerplate was inserted * A "clone_sparse" function was renamed to "clonesparse" to appease the style checker * Paths to the sparse extension in tests reflect built-in location * test-sparse-extensions.t was renamed to test-sparse-fsmonitor.t and references to "simplecache" were removed. The test always skips because it isn't trivial to run it given the way we currently run fsmonitor tests * A double empty line was removed from test-sparse-profiles.t There are aspects of the added code that are obviously not ideal. The goal is to make a minimal number of modifications as part of the vendoring to make it easier to track changes from the original implementation. Refactoring will occur in subsequent patches.
Thu, 06 Jul 2017 15:15:02 -0400 contrib: widen "direct use of `python`" net again
Augie Fackler <augie@google.com> [Thu, 06 Jul 2017 15:15:02 -0400] rev 33288
contrib: widen "direct use of `python`" net again I think I've now caught all of them. Differential Revision: https://phab.mercurial-scm.org/D15
Thu, 06 Jul 2017 14:33:48 -0500 tests: clean up a newly-introduced instance of `python`
Kevin Bullock <kbullock+mercurial@ringworld.org> [Thu, 06 Jul 2017 14:33:48 -0500] rev 33287
tests: clean up a newly-introduced instance of `python` Differential Revision: https://phab.mercurial-scm.org/D16
Tue, 20 Jun 2017 17:31:18 -0400 tests: clean up even more direct `python` calls with $PYTHON
Augie Fackler <augie@google.com> [Tue, 20 Jun 2017 17:31:18 -0400] rev 33286
tests: clean up even more direct `python` calls with $PYTHON This time ones that are prefixed with =, ", ', or `. This appears to be the last of them. Differential Revision: https://phab.mercurial-scm.org/D14
Tue, 20 Jun 2017 17:25:57 -0400 contrib: widen the "don't use `python`" net a little
Augie Fackler <augie@google.com> [Tue, 20 Jun 2017 17:25:57 -0400] rev 33285
contrib: widen the "don't use `python`" net a little I'm still cleaning this up, but it's easier to do in bite-size chunks like this than all at once. The negative lookahead avoids one false positive category from some output related to finding Subversion bindings. Differential Revision: https://phab.mercurial-scm.org/D13
Wed, 05 Jul 2017 13:54:53 +0200 followlines: join merge parents line ranges in blockdescendants() (issue5595)
Denis Laxalde <denis.laxalde@logilab.fr> [Wed, 05 Jul 2017 13:54:53 +0200] rev 33284
followlines: join merge parents line ranges in blockdescendants() (issue5595) In blockdescendants(), we had an assertion when line range of a merge changeset was not consistent depending on which parent was considered for computation. For instance, this might occur when file content (in lookup range) is significantly different between parent branches of the merge as demonstrated in added tests (where we almost completely rewrite the "baz" file while also introducing similarities with its content in the other branch we later merge to). Now, in such case, we combine line ranges from all parents by storing the envelope of both line ranges. This is conservative (the line range is extended, possibly unnecessarily) but at least this should avoid missing descendants with changes in a range that would fall in that of one parent but not in another one (the case of "baz: narrow change (2->2+)" changeset in tests).
Tue, 04 Jul 2017 22:35:52 -0700 workingfilectx: add exists, lexists
Phil Cohen <phillco@fb.com> [Tue, 04 Jul 2017 22:35:52 -0700] rev 33283
workingfilectx: add exists, lexists Switch the lone call in merge.py to use it. As with past refactors, the goal is to make wctx hot-swappable with an in-memory context in the future. This change should be a no-op today.
Tue, 04 Jul 2017 23:13:47 +0900 vfs: add explanation about cost of checkambig=True in corner case
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 04 Jul 2017 23:13:47 +0900] rev 33282
vfs: add explanation about cost of checkambig=True in corner case
Tue, 04 Jul 2017 23:13:47 +0900 vfs: replace avoiding ambiguity in abstractvfs.rename with _avoidambig
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 04 Jul 2017 23:13:47 +0900] rev 33281
vfs: replace avoiding ambiguity in abstractvfs.rename with _avoidambig This centralizes common logic to forcibly avoid file stat ambiguity into _avoidambig(), which was introduced by previous patch.
Tue, 04 Jul 2017 23:13:47 +0900 vfs: copy if EPERM to avoid file stat ambiguity forcibly at closing
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 04 Jul 2017 23:13:47 +0900] rev 33280
vfs: copy if EPERM to avoid file stat ambiguity forcibly at closing Now, files (to be truncated) are opened with checkambig=True, only if localrepository caches it. Therefore, straightforward "copy if EPERM" is always reasonable to avoid file stat ambiguity at closing. This patch makes checkambigatclosing close wrapper copy the target file, and advance mtime on it after renaming, if EPERM. This can avoid file stat ambiguity, even if the target file is owned by another (see issue5418 and issue5584 for detail). This patch factors main logic out instead of changing checkambigatclosing._checkambig() directly, in order to reuse it.
Tue, 04 Jul 2017 23:13:47 +0900 transaction: apply checkambig=True only on limited files for similarity
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 04 Jul 2017 23:13:47 +0900] rev 33279
transaction: apply checkambig=True only on limited files for similarity Now, transaction can determine whether avoidance of file stat ambiguity is needed for each files, by blacklist "checkambigfiles". For similarity to truncation in _playback(), this patch apply checkambig=True only on limited files in code paths below. - restoring files by util.copyfile(), in _playback() (checkambigfiles itself is examined at first, because it as a keyword argument might be None) - writing files at finalization of transaction, in _generatefiles() This patch reduces cost of checking stat at writing out and restoring files, which aren't filecache-ed.
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip