exchangev2: support fetching shallow files history This commit teaches the exchangev2 client code to handle fetching shallow files data. Only shallow fetching of files data is supported: shallow fetching of changeset and manifest data is explicitly not yet supported. Previously, we would fetch file revisions for changesets that were received by the current pull operation. In the new model, we calculate the set of "relevant" changesets given the pull depth and only fetch files data for those changesets. We also teach the "filesdata" command invocation to vary parameters as needed. The implementation here is far from complete or optimal. Subsequent pulls will end up re-fetching a lot of files data. But the application of this data should mostly be a no-op on the client, so it isn't a big deal. Depending on the order file revisions are fetched in, revisions could get inserted with the wrong revision number relationships. I think the best way to deal with this is to remove revision numbers from storage and to either dynamically derive them (by reconstructing a DAG from nodes/parents) or remove revision numbers from the file storage interface completely. A missing API that we'll likely want to write pretty soon is "ensure files for revision(s) are present." We can kind of cajole exchangev2.pull() to do this. But it isn't very efficient. For example, in simple cases like widening the store to obtain data for a single revision, it is probably more efficient to walk the manifest and find exactly which file revisions are missing and to make explicit requests for just their data. In more advanced cases, asking the server for all files data may be more efficient, even though it requires sending data the client already has. There is tons of room for future experimentation here. And TBH I'm not sure what the final state will be. Anyway, this commit gets us pretty close to being able to have shallow and narrow checkouts with exchangev2/sqlite storage. Close enough that a minimal extension should be able to provide fill in the gaps until the code in core stabilizes and there is a user-facing way to trigger the narrow/shallow bits from `hg clone` without also implying using of the narrow extension... Differential Revision: https://phab.mercurial-scm.org/D5169

# pullext.py - Simple extension to test pulling
#
# Copyright 2018 Gregory Szorc <gregory.szorc@gmail.com>
#
# This software may be used and distributed according to the terms of the
# GNU General Public License version 2 or any later version.

from __future__ import absolute_import

from mercurial.i18n import _
from mercurial import (
    commands,
    error,
    extensions,
    localrepo,
    repository,
)

def clonecommand(orig, ui, repo, *args, **kwargs):
    if kwargs.get(r'include') or kwargs.get(r'exclude'):
        kwargs[r'narrow'] = True

    if kwargs.get(r'depth'):
        try:
            kwargs[r'depth'] = int(kwargs[r'depth'])
        except ValueError:
            raise error.Abort(_('--depth must be an integer'))

    return orig(ui, repo, *args, **kwargs)

def featuresetup(ui, features):
    features.add(repository.NARROW_REQUIREMENT)

def extsetup(ui):
    entry = extensions.wrapcommand(commands.table, 'clone', clonecommand)

    hasinclude = any(x[1] == 'include' for x in entry[1])
    hasdepth = any(x[1] == 'depth' for x in entry[1])

    if not hasinclude:
        entry[1].append(('', 'include', [],
                         _('pattern of file/directory to clone')))
        entry[1].append(('', 'exclude', [],
                         _('pattern of file/directory to not clone')))

    if not hasdepth:
        entry[1].append(('', 'depth', '',
                         _('ancestry depth of changesets to fetch')))

    localrepo.featuresetupfuncs.add(featuresetup)