##// END OF EJS Templates
exchangev2: fetch manifest revisions...
exchangev2: fetch manifest revisions Now that the server has support for retrieving manifest data, we can implement the client bits to call it. We teach the changeset fetching code to capture the manifest revisions that are encountered on incoming changesets. We then feed this into a new function which filters out known manifests and then batches up manifest data requests to the server. This is different from the previous wire protocol in a few notable ways. First, the client fetches manifest data separately and explicitly. Before, we'd ask the server for data pertaining to some changesets (via a "getbundle" command) and manifests (and files) would be sent automatically. Providing an API for looking up just manifest data separately gives clients much more flexibility for manifest management. For example, a client may choose to only fetch manifest data on demand instead of prefetching it (i.e. partial clone). Second, we send N commands to the server for manifest retrieval instead of 1. This property has a few nice side-effects. One is that the deterministic nature of the requests lends itself to server-side caching. For example, say the remote has 50,000 manifests. If the server is configured to cache responses, each time a new commit arrives, you will have a cache miss and need to regenerate all outgoing data. But if you makes N requests requesting 10,000 manifests each, a new commit will still yield cache hits on the initial, unchanged manifest batches/requests. A derived benefit from these properties is that resumable clone is conceptually simpler to implement. When making a monolithic request for all of the repository data, recovering from an interrupted clone is hard because the server was in the driver's seat and was maintaining state about all the data that needed transferred. With the client driving fetching, the client can persist the set of unfetched entities and retry/resume a fetch if something goes wrong. Or we can fetch all data N changesets at a time and slowly build up a repository. This approach is drastically easier to implement when we have server APIs exposing low-level repository primitives (such as manifests and files). We don't yet support tree manifests. But it should be possible to implement that with the existing wire protocol command. Differential Revision: https://phab.mercurial-scm.org/D4489

File last commit:

r38806:e7aa113b default
r39674:d292328e default
Show More
diffhelper.py
78 lines | 2.2 KiB | text/x-python | PythonLexer
# diffhelper.py - helper routines for patch
#
# Copyright 2009 Matt Mackall <mpm@selenic.com> and others
#
# 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 .i18n import _
from . import (
error,
pycompat,
)
def addlines(fp, hunk, lena, lenb, a, b):
"""Read lines from fp into the hunk
The hunk is parsed into two arrays, a and b. a gets the old state of
the text, b gets the new state. The control char from the hunk is saved
when inserting into a, but not b (for performance while deleting files.)
"""
while True:
todoa = lena - len(a)
todob = lenb - len(b)
num = max(todoa, todob)
if num == 0:
break
for i in pycompat.xrange(num):
s = fp.readline()
if not s:
raise error.ParseError(_('incomplete hunk'))
if s == "\\ No newline at end of file\n":
fixnewline(hunk, a, b)
continue
if s == '\n' or s == '\r\n':
# Some patches may be missing the control char
# on empty lines. Supply a leading space.
s = ' ' + s
hunk.append(s)
if s.startswith('+'):
b.append(s[1:])
elif s.startswith('-'):
a.append(s)
else:
b.append(s[1:])
a.append(s)
def fixnewline(hunk, a, b):
"""Fix up the last lines of a and b when the patch has no newline at EOF"""
l = hunk[-1]
# tolerate CRLF in last line
if l.endswith('\r\n'):
hline = l[:-2]
else:
hline = l[:-1]
if hline.startswith((' ', '+')):
b[-1] = hline[1:]
if hline.startswith((' ', '-')):
a[-1] = hline
hunk[-1] = hline
def testhunk(a, b, bstart):
"""Compare the lines in a with the lines in b
a is assumed to have a control char at the start of each line, this char
is ignored in the compare.
"""
alen = len(a)
blen = len(b)
if alen > blen - bstart or bstart < 0:
return False
for i in pycompat.xrange(alen):
if a[i][1:] != b[i + bstart]:
return False
return True