##// END OF EJS Templates
exchangev2: support fetching shallow files history...
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

File last commit:

r33573:857876eb merge 4.3-rc stable
r40429:229d23cd default
Show More
mpatch.py
48 lines | 1.4 KiB | text/x-python | PythonLexer
# mpatch.py - CFFI implementation of mpatch.c
#
# Copyright 2016 Maciej Fijalkowski <fijall@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 ..pure.mpatch import *
from ..pure.mpatch import mpatchError # silence pyflakes
from . import _mpatch
ffi = _mpatch.ffi
lib = _mpatch.lib
@ffi.def_extern()
def cffi_get_next_item(arg, pos):
all, bins = ffi.from_handle(arg)
container = ffi.new("struct mpatch_flist*[1]")
to_pass = ffi.new("char[]", str(bins[pos]))
all.append(to_pass)
r = lib.mpatch_decode(to_pass, len(to_pass) - 1, container)
if r < 0:
return ffi.NULL
return container[0]
def patches(text, bins):
lgt = len(bins)
all = []
if not lgt:
return text
arg = (all, bins)
patch = lib.mpatch_fold(ffi.new_handle(arg),
lib.cffi_get_next_item, 0, lgt)
if not patch:
raise mpatchError("cannot decode chunk")
outlen = lib.mpatch_calcsize(len(text), patch)
if outlen < 0:
lib.mpatch_lfree(patch)
raise mpatchError("inconsistency detected")
buf = ffi.new("char[]", outlen)
if lib.mpatch_apply(buf, text, len(text), patch) < 0:
lib.mpatch_lfree(patch)
raise mpatchError("error applying patches")
res = ffi.buffer(buf, outlen)[:]
lib.mpatch_lfree(patch)
return res