sapling/hgext/sparse.py

338 lines
13 KiB
Python
Raw Normal View History

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.
2017-07-01 20:43:29 +03:00
# sparse.py - allow sparse checkouts of the working directory
#
# Copyright 2014 Facebook, Inc.
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.
"""allow sparse checkouts of the working directory (EXPERIMENTAL)
(This extension is not yet protected by backwards compatibility
guarantees. Any aspect may break in future releases until this
notice is removed.)
This extension allows the working directory to only consist of a
subset of files for the revision. This allows specific files or
directories to be explicitly included or excluded. Many repository
operations have performance proportional to the number of files in
the working directory. So only realizing a subset of files in the
working directory can improve performance.
Sparse Config Files
-------------------
The set of files that are part of a sparse checkout are defined by
a sparse config file. The file defines 3 things: includes (files to
include in the sparse checkout), excludes (files to exclude from the
sparse checkout), and profiles (links to other config files).
The file format is newline delimited. Empty lines and lines beginning
with ``#`` are ignored.
Lines beginning with ``%include `` denote another sparse config file
to include. e.g. ``%include tests.sparse``. The filename is relative
to the repository root.
The special lines ``[include]`` and ``[exclude]`` denote the section
for includes and excludes that follow, respectively. It is illegal to
have ``[include]`` after ``[exclude]``.
Non-special lines resemble file patterns to be added to either includes
or excludes. The syntax of these lines is documented by :hg:`help patterns`.
Patterns are interpreted as ``glob:`` by default and match against the
root of the repository.
Exclusion patterns take precedence over inclusion patterns. So even
if a file is explicitly included, an ``[exclude]`` entry can remove it.
For example, say you have a repository with 3 directories, ``frontend/``,
``backend/``, and ``tools/``. ``frontend/`` and ``backend/`` correspond
to different projects and it is uncommon for someone working on one
to need the files for the other. But ``tools/`` contains files shared
between both projects. Your sparse config files may resemble::
# frontend.sparse
frontend/**
tools/**
# backend.sparse
backend/**
tools/**
Say the backend grows in size. Or there's a directory with thousands
of files you wish to exclude. You can modify the profile to exclude
certain files::
[include]
backend/**
tools/**
[exclude]
tools/tests/**
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.
2017-07-01 20:43:29 +03:00
"""
from __future__ import absolute_import
from mercurial.i18n import _
from mercurial import (
cmdutil,
commands,
dirstate,
error,
extensions,
hg,
match as matchmod,
registrar,
sparse,
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.
2017-07-01 20:43:29 +03:00
util,
)
# Note for extension authors: ONLY specify testedwith = 'ships-with-hg-core' for
# extensions which SHIP WITH MERCURIAL. Non-mainline extensions should
# be specifying the version(s) of Mercurial they are tested with, or
# leave the attribute unspecified.
testedwith = 'ships-with-hg-core'
cmdtable = {}
command = registrar.command(cmdtable)
def extsetup(ui):
sparse.enabled = True
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.
2017-07-01 20:43:29 +03:00
_setupclone(ui)
_setuplog(ui)
_setupadd(ui)
_setupdirstate(ui)
def replacefilecache(cls, propname, replacement):
"""Replace a filecache property with a new class. This allows changing the
cache invalidation condition."""
origcls = cls
assert callable(replacement)
while cls is not object:
if propname in cls.__dict__:
orig = cls.__dict__[propname]
setattr(cls, propname, replacement(orig))
break
cls = cls.__bases__[0]
if cls is object:
raise AttributeError(_("type '%s' has no property '%s'") % (origcls,
propname))
def _setuplog(ui):
entry = commands.table['^log|history']
entry[1].append(('', 'sparse', None,
"limit to changesets affecting the sparse checkout"))
def _logrevs(orig, repo, opts):
revs = orig(repo, opts)
if opts.get('sparse'):
sparsematch = sparse.matcher(repo)
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.
2017-07-01 20:43:29 +03:00
def ctxmatch(rev):
ctx = repo[rev]
return any(f for f in ctx.files() if sparsematch(f))
revs = revs.filter(ctxmatch)
return revs
extensions.wrapfunction(cmdutil, '_logrevs', _logrevs)
def _clonesparsecmd(orig, ui, repo, *args, **opts):
include_pat = opts.get('include')
exclude_pat = opts.get('exclude')
enableprofile_pat = opts.get('enable_profile')
include = exclude = enableprofile = False
if include_pat:
pat = include_pat
include = True
if exclude_pat:
pat = exclude_pat
exclude = True
if enableprofile_pat:
pat = enableprofile_pat
enableprofile = True
if sum([include, exclude, enableprofile]) > 1:
raise error.Abort(_("too many flags specified."))
if include or exclude or enableprofile:
def clonesparse(orig, self, node, overwrite, *args, **kwargs):
sparse.updateconfig(self.unfiltered(), pat, {}, include=include,
exclude=exclude, enableprofile=enableprofile,
usereporootpaths=True)
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.
2017-07-01 20:43:29 +03:00
return orig(self, node, overwrite, *args, **kwargs)
extensions.wrapfunction(hg, 'updaterepo', clonesparse)
return orig(ui, repo, *args, **opts)
def _setupclone(ui):
entry = commands.table['^clone']
entry[1].append(('', 'enable-profile', [],
'enable a sparse profile'))
entry[1].append(('', 'include', [],
'include sparse pattern'))
entry[1].append(('', 'exclude', [],
'exclude sparse pattern'))
extensions.wrapcommand(commands.table, 'clone', _clonesparsecmd)
def _setupadd(ui):
entry = commands.table['^add']
entry[1].append(('s', 'sparse', None,
'also include directories of added files in sparse config'))
def _add(orig, ui, repo, *pats, **opts):
if opts.get('sparse'):
dirs = set()
for pat in pats:
dirname, basename = util.split(pat)
dirs.add(dirname)
sparse.updateconfig(repo, list(dirs), opts, include=True)
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.
2017-07-01 20:43:29 +03:00
return orig(ui, repo, *pats, **opts)
extensions.wrapcommand(commands.table, 'add', _add)
def _setupdirstate(ui):
"""Modify the dirstate to prevent stat'ing excluded files,
and to prevent modifications to files outside the checkout.
"""
def walk(orig, self, match, subrepos, unknown, ignored, full=True):
match = matchmod.intersectmatchers(match, self._sparsematcher)
return orig(self, match, subrepos, unknown, ignored, full)
extensions.wrapfunction(dirstate.dirstate, 'walk', walk)
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.
2017-07-01 20:43:29 +03:00
# dirstate.rebuild should not add non-matching files
def _rebuild(orig, self, parent, allfiles, changedfiles=None):
dirstate: expose a sparse matcher on dirstate (API) The sparse extension performs a lot of monkeypatching of dirstate to make it sparse aware. Essentially, various operations need to take the active sparse config into account. They do this by obtaining a matcher representing the sparse config and filtering paths through it. The monkeypatching is done by stuffing a reference to a repo on dirstate and calling sparse.matcher() (which takes a repo instance) during each function call. The reason this function takes a repo instance is because resolving the sparse config may require resolving file contents from filelogs, and that requires a repo. (If the current sparse config references "profile" files, the contents of those files from the dirstate's parent revisions is resolved.) I seem to recall people having strong opinions that the dirstate object not have a reference to a repo. So copying what the sparse extension does probably won't fly in core. Plus, the dirstate modifications shouldn't require a full repo: they only need a matcher. So there's no good reason to stuff a reference to the repo in dirstate. This commit exposes a sparse matcher to dirstate via a property that when looked up will call a function that eventually calls sparse.matcher(). The repo instance is bound in a closure, so it isn't exposed to dirstate. This approach is functionally similar to what the sparse extension does today, except it hides the repo instance from dirstate. The approach is not optimal because we have to call a proxy function and sparse.matcher() on every property lookup. There is room to cache the matcher instance in dirstate. After all, the matcher only changes if the dirstate's parents change or if the sparse config changes. It feels like we should be able to detect both events and update the matcher when this occurs. But for now we preserve the existing semantics so we can move the dirstate sparseness bits into core. Once in core, refactoring becomes a bit easier since it will be clearer how all these components interact. The sparse extension has been updated to use the new property. Because all references to the repo on dirstate have been removed, the code for setting it has been removed.
2017-07-09 02:18:04 +03:00
matcher = self._sparsematcher
if not matcher.always():
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.
2017-07-01 20:43:29 +03:00
allfiles = allfiles.matches(matcher)
if changedfiles:
changedfiles = [f for f in changedfiles if matcher(f)]
if changedfiles is not None:
# In _rebuild, these files will be deleted from the dirstate
# when they are not found to be in allfiles
dirstatefilestoremove = set(f for f in self if not matcher(f))
changedfiles = dirstatefilestoremove.union(changedfiles)
return orig(self, parent, allfiles, changedfiles)
extensions.wrapfunction(dirstate.dirstate, 'rebuild', _rebuild)
# Prevent adding files that are outside the sparse checkout
editfuncs = ['normal', 'add', 'normallookup', 'copy', 'remove', 'merge']
hint = _('include file with `hg debugsparse --include <pattern>` or use ' +
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.
2017-07-01 20:43:29 +03:00
'`hg add -s <file>` to include file directory while adding')
for func in editfuncs:
def _wrapper(orig, self, *args):
dirstate: expose a sparse matcher on dirstate (API) The sparse extension performs a lot of monkeypatching of dirstate to make it sparse aware. Essentially, various operations need to take the active sparse config into account. They do this by obtaining a matcher representing the sparse config and filtering paths through it. The monkeypatching is done by stuffing a reference to a repo on dirstate and calling sparse.matcher() (which takes a repo instance) during each function call. The reason this function takes a repo instance is because resolving the sparse config may require resolving file contents from filelogs, and that requires a repo. (If the current sparse config references "profile" files, the contents of those files from the dirstate's parent revisions is resolved.) I seem to recall people having strong opinions that the dirstate object not have a reference to a repo. So copying what the sparse extension does probably won't fly in core. Plus, the dirstate modifications shouldn't require a full repo: they only need a matcher. So there's no good reason to stuff a reference to the repo in dirstate. This commit exposes a sparse matcher to dirstate via a property that when looked up will call a function that eventually calls sparse.matcher(). The repo instance is bound in a closure, so it isn't exposed to dirstate. This approach is functionally similar to what the sparse extension does today, except it hides the repo instance from dirstate. The approach is not optimal because we have to call a proxy function and sparse.matcher() on every property lookup. There is room to cache the matcher instance in dirstate. After all, the matcher only changes if the dirstate's parents change or if the sparse config changes. It feels like we should be able to detect both events and update the matcher when this occurs. But for now we preserve the existing semantics so we can move the dirstate sparseness bits into core. Once in core, refactoring becomes a bit easier since it will be clearer how all these components interact. The sparse extension has been updated to use the new property. Because all references to the repo on dirstate have been removed, the code for setting it has been removed.
2017-07-09 02:18:04 +03:00
sparsematch = self._sparsematcher
if not sparsematch.always():
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.
2017-07-01 20:43:29 +03:00
for f in args:
if (f is not None and not sparsematch(f) and
f not in self):
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.
2017-07-01 20:43:29 +03:00
raise error.Abort(_("cannot add '%s' - it is outside "
"the sparse checkout") % f,
hint=hint)
return orig(self, *args)
extensions.wrapfunction(dirstate.dirstate, func, _wrapper)
@command('^debugsparse', [
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.
2017-07-01 20:43:29 +03:00
('I', 'include', False, _('include files in the sparse checkout')),
('X', 'exclude', False, _('exclude files in the sparse checkout')),
('d', 'delete', False, _('delete an include/exclude rule')),
('f', 'force', False, _('allow changing rules even with pending changes')),
('', 'enable-profile', False, _('enables the specified profile')),
('', 'disable-profile', False, _('disables the specified profile')),
('', 'import-rules', False, _('imports rules from a file')),
('', 'clear-rules', False, _('clears local include/exclude rules')),
('', 'refresh', False, _('updates the working after sparseness changes')),
('', 'reset', False, _('makes the repo full again')),
] + commands.templateopts,
_('[--OPTION] PATTERN...'))
def debugsparse(ui, repo, *pats, **opts):
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.
2017-07-01 20:43:29 +03:00
"""make the current checkout sparse, or edit the existing checkout
The sparse command is used to make the current checkout sparse.
This means files that don't meet the sparse condition will not be
written to disk, or show up in any working copy operations. It does
not affect files in history in any way.
Passing no arguments prints the currently applied sparse rules.
--include and --exclude are used to add and remove files from the sparse
checkout. The effects of adding an include or exclude rule are applied
immediately. If applying the new rule would cause a file with pending
changes to be added or removed, the command will fail. Pass --force to
force a rule change even with pending changes (the changes on disk will
be preserved).
--delete removes an existing include/exclude rule. The effects are
immediate.
--refresh refreshes the files on disk based on the sparse rules. This is
only necessary if .hg/sparse was changed by hand.
--enable-profile and --disable-profile accept a path to a .hgsparse file.
This allows defining sparse checkouts and tracking them inside the
repository. This is useful for defining commonly used sparse checkouts for
many people to use. As the profile definition changes over time, the sparse
checkout will automatically be updated appropriately, depending on which
changeset is checked out. Changes to .hgsparse are not applied until they
have been committed.
--import-rules accepts a path to a file containing rules in the .hgsparse
format, allowing you to add --include, --exclude and --enable-profile rules
in bulk. Like the --include, --exclude and --enable-profile switches, the
changes are applied immediately.
--clear-rules removes all local include and exclude rules, while leaving
any enabled profiles in place.
Returns 0 if editing the sparse checkout succeeds.
"""
include = opts.get('include')
exclude = opts.get('exclude')
force = opts.get('force')
enableprofile = opts.get('enable_profile')
disableprofile = opts.get('disable_profile')
importrules = opts.get('import_rules')
clearrules = opts.get('clear_rules')
delete = opts.get('delete')
refresh = opts.get('refresh')
reset = opts.get('reset')
count = sum([include, exclude, enableprofile, disableprofile, delete,
importrules, refresh, clearrules, reset])
if count > 1:
raise error.Abort(_("too many flags specified"))
if count == 0:
if repo.vfs.exists('sparse'):
ui.status(repo.vfs.read("sparse") + "\n")
temporaryincludes = sparse.readtemporaryincludes(repo)
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.
2017-07-01 20:43:29 +03:00
if temporaryincludes:
ui.status(_("Temporarily Included Files (for merge/rebase):\n"))
ui.status(("\n".join(temporaryincludes) + "\n"))
else:
ui.status(_('repo is not sparse\n'))
return
if include or exclude or delete or reset or enableprofile or disableprofile:
sparse.updateconfig(repo, pats, opts, include=include, exclude=exclude,
reset=reset, delete=delete,
enableprofile=enableprofile,
disableprofile=disableprofile, force=force)
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.
2017-07-01 20:43:29 +03:00
if importrules:
sparse.importfromfiles(repo, opts, pats, force=force)
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.
2017-07-01 20:43:29 +03:00
if clearrules:
sparse.clearrules(repo, force=force)
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.
2017-07-01 20:43:29 +03:00
if refresh:
try:
wlock = repo.wlock()
fcounts = map(
len,
sparse.refreshwdir(repo, repo.status(), sparse.matcher(repo),
force=force))
sparse.printchanges(ui, opts, added=fcounts[0], dropped=fcounts[1],
conflicting=fcounts[2])
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.
2017-07-01 20:43:29 +03:00
finally:
wlock.release()