Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 12:31:19 -0700] rev 26647
exchange: extract bundle specification components into own attributes
An upcoming patch will enable clients to prefer certain bundles over
others. The idea is that we define values of attributes from manifests
that are desirable.
The BUNDLESPEC attribute is a complex value consisting of multiple
parts. Clients may wish to only prefer one of these parts. Having to
specify every combination of BUNDLESPEC would be annoying. So, we
extract the components of BUNDLESPEC into their own attributes so
clients can easily filter on a sub-component.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 12:29:50 -0700] rev 26646
exchange: support preserving external names when parsing bundle specs
This will be needed to make client-side preferences work easier.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 10:59:41 -0700] rev 26645
clonebundles: filter on SNI requirement
Server Name Indication (SNI) is commonly used in CDNs and other hosted
environments. Unfortunately, Python <2.7.9 does not support SNI and when
these older Python versions attempt to negotiate TLS to an SNI server,
they raise an opaque error like
"_ssl.c:507: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert
handshake failure."
We introduce a manifest attribute to denote the URL requires SNI and
have clients without SNI support filter these entries.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 11:45:30 -0700] rev 26644
clonebundles: filter on bundle specification
Not all clients are capable of reading every bundle. Currently, content
negotiation to ensure a server sends a client a compatible bundle
format is performed at request time. The response bundle is dynamically
generated at request time, so this works fine.
Clone bundles are statically generated *before* the request. This means
that a modern server could produce bundles that a legacy client isn't
capable of reading. Without some kind of "type hint" in the clone
bundles manifest, a client may attempt to download an incompatible
bundle. Furthermore, a client may not realize a bundle is incompatible
until it has processed part of the bundle (imagine consuming a 1 GB
changegroup bundle2 part only to discover the bundle2 part afterwards is
incompatibl). This would waste time and resources. And it isn't very
user friendly.
Clone bundle manifests thus need to advertise the *exact* format of the
hosted bundles so clients may filter out entries that they don't know
how to read. This patch introduces that mechanism.
We introduce the BUNDLESPEC attribute to declare the "bundle
specification" of the entry. Bundle specifications are parsed using
exchange.parsebundlespecification, which uses the same strings as the
"--type" argument to `hg bundle`. The supported bundle specifications
are well defined and backwards compatible.
When a client encounters a BUNDLESPEC that is invalid or unsupported, it
silently ignores the entry.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 10:41:54 -0700] rev 26643
clonebundle: support bundle2
exchange.readbundle() can return 2 different types. We weren't handling
the bundle2 case. Handle it.
At some point we'll likely want a generic API for applying a bundle from
a file handle. For now, create another one-off until we figure out what
the unified bundle API should look like (addressing this is a can of
worms I don't want to open right now).
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 05 Oct 2015 21:31:32 -0700] rev 26642
update: also use 'destupdate' for pull and unbundle
Update can also be performed by 'hg pull --update' and 'hg unbundle'. We use the
destupdate function in these case too.
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 29 Sep 2015 01:03:26 -0700] rev 26641
destupdate: also include bookmark related logic
For the same reason, we move the bookmark related update logic into the
'destupdate' function. This requires to extend the returns of the function to
include the bookmark that needs to move (more or less) and the bookmark to
activate at the end of the function. See function documentation for details on
this returns.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 10:57:54 -0700] rev 26640
exchange: refactor bundle specification parsing
The old code was tailored to `hg bundle` usage and not appropriate for
use as a general API, which clone bundles will require. The code has
been rewritten to make it more generally suitable.
We introduce dedicated error types to represent invalid and unsupported
bundle specifications. The reason we need dedicated error types (rather
than error.Abort) is because clone bundles will want to catch these
exception as part of filtering entries. We don't want to swallow
error.Abort on principle.
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 13 Oct 2015 11:43:21 -0700] rev 26639
exchange: move bundle specification parsing from cmdutil
Clone bundles require a well-defined string to specify the type of
bundle that is listed so clients can filter compatible file types. The
`hg bundle` command and cmdutil.parsebundletype() already establish the
beginnings of a bundle specification format.
As part of formalizing this format specification so it can be used by
clone bundles, we move the specification parsing bits verbatim to
exchange.py, which is a more suitable place than cmdutil.py. A
subsequent patch will refactor this code to make it more appropriate as
a general API.
Yuya Nishihara <yuya@tcha.org> [Tue, 24 Mar 2015 00:28:28 +0900] rev 26638
revset: add optional offset argument to limit() predicate
It's common for GUI or web frontend to fetch chunk of revisions per batch
size. Previously it was possible only if revisions were sorted by revision
number.
$ hg log -r 'limit({revspec} & :{last_known}, 101)'
So this patch introduces a general way to retrieve chunk of revisions after
skipping offset revisions.
$ hg log -r 'limit({revspec}, 100, {last_count})'
This is a dumb implementation. We can optimize it for baseset and spanset
later.