2019-05-28 13:12:27 +03:00
|
|
|
$ setconfig extensions.treemanifest=!
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
#require killdaemons
|
|
|
|
|
|
|
|
Create an extension to test bundle2 remote-changegroup parts
|
|
|
|
|
|
|
|
$ cat > bundle2.py << EOF
|
|
|
|
> """A small extension to test bundle2 remote-changegroup parts.
|
|
|
|
>
|
|
|
|
> Current bundle2 implementation doesn't provide a way to generate those
|
|
|
|
> parts, so they must be created by extensions.
|
|
|
|
> """
|
2019-01-30 03:25:33 +03:00
|
|
|
> from edenscm.mercurial import bundle2, changegroup, discovery, exchange, util
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
>
|
|
|
|
> def _getbundlechangegrouppart(bundler, repo, source, bundlecaps=None,
|
|
|
|
> b2caps=None, heads=None, common=None,
|
|
|
|
> **kwargs):
|
|
|
|
> """this function replaces the changegroup part handler for getbundle.
|
|
|
|
> It allows to create a set of arbitrary parts containing changegroups
|
|
|
|
> and remote-changegroups, as described in a bundle2maker file in the
|
|
|
|
> repository .hg/ directory.
|
|
|
|
>
|
|
|
|
> Each line of that bundle2maker file contain a description of the
|
|
|
|
> part to add:
|
|
|
|
> - changegroup common_revset heads_revset
|
|
|
|
> Creates a changegroup part based, using common_revset and
|
2016-08-09 18:00:38 +03:00
|
|
|
> heads_revset for outgoing
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> - remote-changegroup url file
|
|
|
|
> Creates a remote-changegroup part for a bundle at the given
|
|
|
|
> url. Size and digest, as required by the client, are computed
|
|
|
|
> from the given file.
|
|
|
|
> - raw-remote-changegroup <python expression>
|
|
|
|
> Creates a remote-changegroup part with the data given in the
|
2017-07-05 19:09:55 +03:00
|
|
|
> Python expression as parameters. The Python expression is
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> evaluated with eval, and is expected to be a dict.
|
|
|
|
> """
|
|
|
|
> def newpart(name, data=''):
|
|
|
|
> """wrapper around bundler.newpart adding an extra part making the
|
|
|
|
> client output information about each processed part"""
|
2015-04-09 23:25:48 +03:00
|
|
|
> bundler.newpart('output', data=name)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> part = bundler.newpart(name, data=data)
|
|
|
|
> return part
|
|
|
|
>
|
2018-09-28 17:08:51 +03:00
|
|
|
> for line in open(repo.localvfs.join('bundle2maker'), 'r'):
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> line = line.strip()
|
|
|
|
> try:
|
|
|
|
> verb, args = line.split(None, 1)
|
|
|
|
> except ValueError:
|
|
|
|
> verb, args = line, ''
|
|
|
|
> if verb == 'remote-changegroup':
|
|
|
|
> url, file = args.split()
|
|
|
|
> bundledata = open(file, 'rb').read()
|
|
|
|
> digest = util.digester.preferred(b2caps['digests'])
|
|
|
|
> d = util.digester([digest], bundledata)
|
2015-04-09 23:25:48 +03:00
|
|
|
> part = newpart('remote-changegroup')
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> part.addparam('url', url)
|
|
|
|
> part.addparam('size', str(len(bundledata)))
|
|
|
|
> part.addparam('digests', digest)
|
|
|
|
> part.addparam('digest:%s' % digest, d[digest])
|
|
|
|
> elif verb == 'raw-remote-changegroup':
|
2015-04-09 23:25:48 +03:00
|
|
|
> part = newpart('remote-changegroup')
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> for k, v in eval(args).items():
|
|
|
|
> part.addparam(k, str(v))
|
|
|
|
> elif verb == 'changegroup':
|
|
|
|
> _common, heads = args.split()
|
|
|
|
> common.extend(repo.lookup(r) for r in repo.revs(_common))
|
|
|
|
> heads = [repo.lookup(r) for r in repo.revs(heads)]
|
2016-08-09 18:00:38 +03:00
|
|
|
> outgoing = discovery.outgoing(repo, common, heads)
|
2018-04-12 02:04:41 +03:00
|
|
|
> cg = changegroup.makechangegroup(repo, outgoing, '02',
|
2017-09-11 04:50:12 +03:00
|
|
|
> 'changegroup')
|
2018-04-12 02:04:41 +03:00
|
|
|
> part = newpart('changegroup', cg.getchunks())
|
|
|
|
> part.addparam('version', '02')
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> else:
|
|
|
|
> raise Exception('unknown verb')
|
|
|
|
>
|
|
|
|
> exchange.getbundle2partsmapping['changegroup'] = _getbundlechangegrouppart
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
Start a simple HTTP server to serve bundles
|
|
|
|
|
2017-06-20 16:45:02 +03:00
|
|
|
$ $PYTHON "$TESTDIR/dumbhttp.py" -p $HGPORT --pid dumb.pid
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
$ cat dumb.pid >> $DAEMON_PIDS
|
|
|
|
|
|
|
|
$ cat >> $HGRCPATH << EOF
|
|
|
|
> [ui]
|
2017-06-21 00:31:18 +03:00
|
|
|
> ssh=$PYTHON "$TESTDIR/dummyssh"
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> logtemplate={rev}:{node|short} {phase} {author} {bookmarks} {desc|firstline}
|
2018-04-12 02:04:53 +03:00
|
|
|
> [format]
|
|
|
|
> allowbundle1=True
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> EOF
|
|
|
|
|
|
|
|
$ hg init repo
|
|
|
|
|
|
|
|
$ hg -R repo unbundle $TESTDIR/bundles/rebase.hg
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 8 changesets with 7 changes to 7 files (+2 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:02de42196ebe
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
|
|
|
|
$ hg -R repo log -G
|
|
|
|
o 7:02de42196ebe draft Nicolas Dumazet <nicdumz.commits@gmail.com> H
|
|
|
|
|
|
|
|
|
| o 6:eea13746799a draft Nicolas Dumazet <nicdumz.commits@gmail.com> G
|
|
|
|
|/|
|
|
|
|
o | 5:24b6387c8c8c draft Nicolas Dumazet <nicdumz.commits@gmail.com> F
|
|
|
|
| |
|
|
|
|
| o 4:9520eea781bc draft Nicolas Dumazet <nicdumz.commits@gmail.com> E
|
|
|
|
|/
|
|
|
|
| o 3:32af7686d403 draft Nicolas Dumazet <nicdumz.commits@gmail.com> D
|
|
|
|
| |
|
|
|
|
| o 2:5fddd98957c8 draft Nicolas Dumazet <nicdumz.commits@gmail.com> C
|
|
|
|
| |
|
|
|
|
| o 1:42ccdea3bb16 draft Nicolas Dumazet <nicdumz.commits@gmail.com> B
|
|
|
|
|/
|
|
|
|
o 0:cd010b8cd998 draft Nicolas Dumazet <nicdumz.commits@gmail.com> A
|
|
|
|
|
|
|
|
$ hg clone repo orig
|
|
|
|
updating to branch default
|
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
|
|
|
|
$ cat > repo/.hg/hgrc << EOF
|
|
|
|
> [extensions]
|
|
|
|
> bundle2=$TESTTMP/bundle2.py
|
|
|
|
> EOF
|
|
|
|
|
|
|
|
Test a pull with an remote-changegroup
|
|
|
|
|
2015-10-16 04:53:57 +03:00
|
|
|
$ hg bundle -R repo --type v1 --base '0:4' -r '5:7' bundle.hg
|
2018-04-12 02:04:30 +03:00
|
|
|
devel-warn: using deprecated bundlev1 format
|
|
|
|
at: */changegroup.py:* (makechangegroup) (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
3 changesets found
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> remote-changegroup http://localhost:$HGPORT/bundle.hg bundle.hg
|
|
|
|
> EOF
|
|
|
|
$ hg clone orig clone -r 3 -r 4
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 5 changesets with 5 changes to 5 files (+1 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:9520eea781bc
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
updating to branch default
|
|
|
|
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 3 changesets with 2 changes to 2 files (+1 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets 24b6387c8c8c:02de42196ebe
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
$ hg -R clone log -G
|
|
|
|
o 7:02de42196ebe public Nicolas Dumazet <nicdumz.commits@gmail.com> H
|
|
|
|
|
|
|
|
|
| o 6:eea13746799a public Nicolas Dumazet <nicdumz.commits@gmail.com> G
|
|
|
|
|/|
|
|
|
|
o | 5:24b6387c8c8c public Nicolas Dumazet <nicdumz.commits@gmail.com> F
|
|
|
|
| |
|
|
|
|
| o 4:9520eea781bc public Nicolas Dumazet <nicdumz.commits@gmail.com> E
|
|
|
|
|/
|
|
|
|
| @ 3:32af7686d403 public Nicolas Dumazet <nicdumz.commits@gmail.com> D
|
|
|
|
| |
|
|
|
|
| o 2:5fddd98957c8 public Nicolas Dumazet <nicdumz.commits@gmail.com> C
|
|
|
|
| |
|
|
|
|
| o 1:42ccdea3bb16 public Nicolas Dumazet <nicdumz.commits@gmail.com> B
|
|
|
|
|/
|
|
|
|
o 0:cd010b8cd998 public Nicolas Dumazet <nicdumz.commits@gmail.com> A
|
|
|
|
|
|
|
|
$ rm -rf clone
|
|
|
|
|
|
|
|
Test a pull with an remote-changegroup and a following changegroup
|
|
|
|
|
2015-10-16 04:53:57 +03:00
|
|
|
$ hg bundle -R repo --type v1 --base 2 -r '3:4' bundle2.hg
|
2018-04-12 02:04:30 +03:00
|
|
|
devel-warn: using deprecated bundlev1 format
|
|
|
|
at: */changegroup.py:* (makechangegroup) (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
2 changesets found
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> remote-changegroup http://localhost:$HGPORT/bundle2.hg bundle2.hg
|
|
|
|
> changegroup 0:4 5:7
|
|
|
|
> EOF
|
|
|
|
$ hg clone orig clone -r 2
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 3 changesets with 3 changes to 3 files
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:5fddd98957c8
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
updating to branch default
|
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 2 changesets with 2 changes to 2 files (+1 heads)
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 3 changesets with 2 changes to 2 files (+1 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets 32af7686d403:02de42196ebe
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
$ hg -R clone log -G
|
|
|
|
o 7:02de42196ebe public Nicolas Dumazet <nicdumz.commits@gmail.com> H
|
|
|
|
|
|
|
|
|
| o 6:eea13746799a public Nicolas Dumazet <nicdumz.commits@gmail.com> G
|
|
|
|
|/|
|
|
|
|
o | 5:24b6387c8c8c public Nicolas Dumazet <nicdumz.commits@gmail.com> F
|
|
|
|
| |
|
|
|
|
| o 4:9520eea781bc public Nicolas Dumazet <nicdumz.commits@gmail.com> E
|
|
|
|
|/
|
|
|
|
| o 3:32af7686d403 public Nicolas Dumazet <nicdumz.commits@gmail.com> D
|
|
|
|
| |
|
|
|
|
| @ 2:5fddd98957c8 public Nicolas Dumazet <nicdumz.commits@gmail.com> C
|
|
|
|
| |
|
|
|
|
| o 1:42ccdea3bb16 public Nicolas Dumazet <nicdumz.commits@gmail.com> B
|
|
|
|
|/
|
|
|
|
o 0:cd010b8cd998 public Nicolas Dumazet <nicdumz.commits@gmail.com> A
|
|
|
|
|
|
|
|
$ rm -rf clone
|
|
|
|
|
|
|
|
Test a pull with a changegroup followed by an remote-changegroup
|
|
|
|
|
2015-10-16 04:53:57 +03:00
|
|
|
$ hg bundle -R repo --type v1 --base '0:4' -r '5:7' bundle3.hg
|
2018-04-12 02:04:30 +03:00
|
|
|
devel-warn: using deprecated bundlev1 format
|
|
|
|
at: */changegroup.py:* (makechangegroup) (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
3 changesets found
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> changegroup 000000000000 :4
|
|
|
|
> remote-changegroup http://localhost:$HGPORT/bundle3.hg bundle3.hg
|
|
|
|
> EOF
|
|
|
|
$ hg clone orig clone -r 2
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 3 changesets with 3 changes to 3 files
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:5fddd98957c8
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
updating to branch default
|
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 2 changesets with 2 changes to 2 files (+1 heads)
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 3 changesets with 2 changes to 2 files (+1 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets 32af7686d403:02de42196ebe
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
$ hg -R clone log -G
|
|
|
|
o 7:02de42196ebe public Nicolas Dumazet <nicdumz.commits@gmail.com> H
|
|
|
|
|
|
|
|
|
| o 6:eea13746799a public Nicolas Dumazet <nicdumz.commits@gmail.com> G
|
|
|
|
|/|
|
|
|
|
o | 5:24b6387c8c8c public Nicolas Dumazet <nicdumz.commits@gmail.com> F
|
|
|
|
| |
|
|
|
|
| o 4:9520eea781bc public Nicolas Dumazet <nicdumz.commits@gmail.com> E
|
|
|
|
|/
|
|
|
|
| o 3:32af7686d403 public Nicolas Dumazet <nicdumz.commits@gmail.com> D
|
|
|
|
| |
|
|
|
|
| @ 2:5fddd98957c8 public Nicolas Dumazet <nicdumz.commits@gmail.com> C
|
|
|
|
| |
|
|
|
|
| o 1:42ccdea3bb16 public Nicolas Dumazet <nicdumz.commits@gmail.com> B
|
|
|
|
|/
|
|
|
|
o 0:cd010b8cd998 public Nicolas Dumazet <nicdumz.commits@gmail.com> A
|
|
|
|
|
|
|
|
$ rm -rf clone
|
|
|
|
|
|
|
|
Test a pull with two remote-changegroups and a changegroup
|
|
|
|
|
2015-10-16 04:53:57 +03:00
|
|
|
$ hg bundle -R repo --type v1 --base 2 -r '3:4' bundle4.hg
|
2018-04-12 02:04:30 +03:00
|
|
|
devel-warn: using deprecated bundlev1 format
|
|
|
|
at: */changegroup.py:* (makechangegroup) (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
2 changesets found
|
2015-10-16 04:53:57 +03:00
|
|
|
$ hg bundle -R repo --type v1 --base '3:4' -r '5:6' bundle5.hg
|
2018-04-12 02:04:30 +03:00
|
|
|
devel-warn: using deprecated bundlev1 format
|
|
|
|
at: */changegroup.py:* (makechangegroup) (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
2 changesets found
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> remote-changegroup http://localhost:$HGPORT/bundle4.hg bundle4.hg
|
|
|
|
> remote-changegroup http://localhost:$HGPORT/bundle5.hg bundle5.hg
|
|
|
|
> changegroup 0:6 7
|
|
|
|
> EOF
|
|
|
|
$ hg clone orig clone -r 2
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 3 changesets with 3 changes to 3 files
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:5fddd98957c8
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
updating to branch default
|
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 2 changesets with 2 changes to 2 files (+1 heads)
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 2 changesets with 1 changes to 1 files
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 1 changesets with 1 changes to 1 files (+1 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets 32af7686d403:02de42196ebe
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
$ hg -R clone log -G
|
|
|
|
o 7:02de42196ebe public Nicolas Dumazet <nicdumz.commits@gmail.com> H
|
|
|
|
|
|
|
|
|
| o 6:eea13746799a public Nicolas Dumazet <nicdumz.commits@gmail.com> G
|
|
|
|
|/|
|
|
|
|
o | 5:24b6387c8c8c public Nicolas Dumazet <nicdumz.commits@gmail.com> F
|
|
|
|
| |
|
|
|
|
| o 4:9520eea781bc public Nicolas Dumazet <nicdumz.commits@gmail.com> E
|
|
|
|
|/
|
|
|
|
| o 3:32af7686d403 public Nicolas Dumazet <nicdumz.commits@gmail.com> D
|
|
|
|
| |
|
|
|
|
| @ 2:5fddd98957c8 public Nicolas Dumazet <nicdumz.commits@gmail.com> C
|
|
|
|
| |
|
|
|
|
| o 1:42ccdea3bb16 public Nicolas Dumazet <nicdumz.commits@gmail.com> B
|
|
|
|
|/
|
|
|
|
o 0:cd010b8cd998 public Nicolas Dumazet <nicdumz.commits@gmail.com> A
|
|
|
|
|
|
|
|
$ rm -rf clone
|
|
|
|
|
|
|
|
Hash digest tests
|
|
|
|
|
2015-10-16 04:53:57 +03:00
|
|
|
$ hg bundle -R repo --type v1 -a bundle6.hg
|
2018-04-12 02:04:30 +03:00
|
|
|
devel-warn: using deprecated bundlev1 format
|
|
|
|
at: */changegroup.py:* (makechangegroup) (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
8 changesets found
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle6.hg', 'size': 1663, 'digests': 'sha1', 'digest:sha1': '2c880cfec23cff7d8f80c2f12958d1563cbdaba6'}
|
|
|
|
> EOF
|
|
|
|
$ hg clone ssh://user@dummy/repo clone
|
|
|
|
requesting all changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 8 changesets with 7 changes to 7 files (+2 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:02de42196ebe
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
updating to branch default
|
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ rm -rf clone
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle6.hg', 'size': 1663, 'digests': 'md5', 'digest:md5': 'e22172c2907ef88794b7bea6642c2394'}
|
|
|
|
> EOF
|
|
|
|
$ hg clone ssh://user@dummy/repo clone
|
|
|
|
requesting all changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 8 changesets with 7 changes to 7 files (+2 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:02de42196ebe
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
updating to branch default
|
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ rm -rf clone
|
|
|
|
|
|
|
|
Hash digest mismatch throws an error
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle6.hg', 'size': 1663, 'digests': 'sha1', 'digest:sha1': '0' * 40}
|
|
|
|
> EOF
|
|
|
|
$ hg clone ssh://user@dummy/repo clone
|
|
|
|
requesting all changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 8 changesets with 7 changes to 7 files (+2 heads)
|
|
|
|
transaction abort!
|
|
|
|
rollback completed
|
2018-02-08 02:18:29 +03:00
|
|
|
abort: bundle at http://localhost:$HGPORT/bundle6.hg is corrupted: (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
sha1 mismatch: expected 0000000000000000000000000000000000000000, got 2c880cfec23cff7d8f80c2f12958d1563cbdaba6
|
|
|
|
[255]
|
|
|
|
|
|
|
|
Multiple hash digests can be given
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle6.hg', 'size': 1663, 'digests': 'md5 sha1', 'digest:md5': 'e22172c2907ef88794b7bea6642c2394', 'digest:sha1': '2c880cfec23cff7d8f80c2f12958d1563cbdaba6'}
|
|
|
|
> EOF
|
|
|
|
$ hg clone ssh://user@dummy/repo clone
|
|
|
|
requesting all changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 8 changesets with 7 changes to 7 files (+2 heads)
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:02de42196ebe
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
updating to branch default
|
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
$ rm -rf clone
|
|
|
|
|
|
|
|
If either of the multiple hash digests mismatches, an error is thrown
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle6.hg', 'size': 1663, 'digests': 'md5 sha1', 'digest:md5': '0' * 32, 'digest:sha1': '2c880cfec23cff7d8f80c2f12958d1563cbdaba6'}
|
|
|
|
> EOF
|
|
|
|
$ hg clone ssh://user@dummy/repo clone
|
|
|
|
requesting all changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 8 changesets with 7 changes to 7 files (+2 heads)
|
|
|
|
transaction abort!
|
|
|
|
rollback completed
|
2018-02-08 02:18:29 +03:00
|
|
|
abort: bundle at http://localhost:$HGPORT/bundle6.hg is corrupted: (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
md5 mismatch: expected 00000000000000000000000000000000, got e22172c2907ef88794b7bea6642c2394
|
|
|
|
[255]
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle6.hg', 'size': 1663, 'digests': 'md5 sha1', 'digest:md5': 'e22172c2907ef88794b7bea6642c2394', 'digest:sha1': '0' * 40}
|
|
|
|
> EOF
|
|
|
|
$ hg clone ssh://user@dummy/repo clone
|
|
|
|
requesting all changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 8 changesets with 7 changes to 7 files (+2 heads)
|
|
|
|
transaction abort!
|
|
|
|
rollback completed
|
2018-02-08 02:18:29 +03:00
|
|
|
abort: bundle at http://localhost:$HGPORT/bundle6.hg is corrupted: (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
sha1 mismatch: expected 0000000000000000000000000000000000000000, got 2c880cfec23cff7d8f80c2f12958d1563cbdaba6
|
|
|
|
[255]
|
|
|
|
|
|
|
|
Corruption tests
|
|
|
|
|
|
|
|
$ hg clone orig clone -r 2
|
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 3 changesets with 3 changes to 3 files
|
2017-10-12 10:39:50 +03:00
|
|
|
new changesets cd010b8cd998:5fddd98957c8
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
updating to branch default
|
|
|
|
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> remote-changegroup http://localhost:$HGPORT/bundle4.hg bundle4.hg
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle5.hg', 'size': 578, 'digests': 'sha1', 'digest:sha1': '0' * 40}
|
|
|
|
> changegroup 0:6 7
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 2 changesets with 2 changes to 2 files (+1 heads)
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 2 changesets with 1 changes to 1 files
|
|
|
|
transaction abort!
|
|
|
|
rollback completed
|
2018-02-08 02:18:29 +03:00
|
|
|
abort: bundle at http://localhost:$HGPORT/bundle5.hg is corrupted: (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
sha1 mismatch: expected 0000000000000000000000000000000000000000, got f29485d6bfd37db99983cfc95ecb52f8ca396106
|
|
|
|
[255]
|
|
|
|
|
|
|
|
The entire transaction has been rolled back in the pull above
|
|
|
|
|
|
|
|
$ hg -R clone log -G
|
|
|
|
@ 2:5fddd98957c8 public Nicolas Dumazet <nicdumz.commits@gmail.com> C
|
|
|
|
|
|
|
|
|
o 1:42ccdea3bb16 public Nicolas Dumazet <nicdumz.commits@gmail.com> B
|
|
|
|
|
|
|
|
|
o 0:cd010b8cd998 public Nicolas Dumazet <nicdumz.commits@gmail.com> A
|
|
|
|
|
|
|
|
|
|
|
|
No params
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {}
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
abort: remote-changegroup: missing "url" param
|
|
|
|
[255]
|
|
|
|
|
|
|
|
Missing size
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle4.hg'}
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
abort: remote-changegroup: missing "size" param
|
|
|
|
[255]
|
|
|
|
|
|
|
|
Invalid size
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle4.hg', 'size': 'foo'}
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
abort: remote-changegroup: invalid value for param "size"
|
|
|
|
[255]
|
|
|
|
|
|
|
|
Size mismatch
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle4.hg', 'size': 42}
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
adding changesets
|
|
|
|
adding manifests
|
|
|
|
adding file changes
|
|
|
|
added 2 changesets with 2 changes to 2 files (+1 heads)
|
|
|
|
transaction abort!
|
|
|
|
rollback completed
|
2018-02-08 02:18:29 +03:00
|
|
|
abort: bundle at http://localhost:$HGPORT/bundle4.hg is corrupted: (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
size mismatch: expected 42, got 581
|
|
|
|
[255]
|
|
|
|
|
|
|
|
Unknown digest
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle4.hg', 'size': 581, 'digests': 'foo', 'digest:foo': 'bar'}
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
|
|
|
abort: missing support for remote-changegroup - digest:foo
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
[255]
|
|
|
|
|
|
|
|
Missing digest
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'http://localhost:$HGPORT/bundle4.hg', 'size': 581, 'digests': 'sha1'}
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
abort: remote-changegroup: missing "digest:sha1" param
|
|
|
|
[255]
|
|
|
|
|
|
|
|
Not an HTTP url
|
|
|
|
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> raw-remote-changegroup {'url': 'ssh://localhost:$HGPORT/bundle4.hg', 'size': 581}
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
abort: remote-changegroup does not support ssh urls
|
|
|
|
[255]
|
|
|
|
|
|
|
|
Not a bundle
|
|
|
|
|
|
|
|
$ cat > notbundle.hg << EOF
|
|
|
|
> foo
|
|
|
|
> EOF
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> remote-changegroup http://localhost:$HGPORT/notbundle.hg notbundle.hg
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
2018-02-08 02:18:29 +03:00
|
|
|
abort: http://localhost:$HGPORT/notbundle.hg: not a Mercurial bundle (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
[255]
|
|
|
|
|
|
|
|
Not a bundle 1.0
|
|
|
|
|
|
|
|
$ cat > notbundle10.hg << EOF
|
2015-04-09 23:25:48 +03:00
|
|
|
> HG20
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
> EOF
|
|
|
|
$ cat > repo/.hg/bundle2maker << EOF
|
|
|
|
> remote-changegroup http://localhost:$HGPORT/notbundle10.hg notbundle10.hg
|
|
|
|
> EOF
|
|
|
|
$ hg pull -R clone ssh://user@dummy/repo
|
|
|
|
pulling from ssh://user@dummy/repo
|
|
|
|
searching for changes
|
2015-04-09 23:25:48 +03:00
|
|
|
remote: remote-changegroup
|
2018-02-08 02:18:29 +03:00
|
|
|
abort: http://localhost:$HGPORT/notbundle10.hg: not a bundle version 1.0 (glob)
|
bundle2: client side support for a part to import external bundles
Bundle2 opens doors to advanced features allowing to reduce load on
mercurial servers, and improve clone experience for users on unstable or
slow networks.
For instance, it could be possible to pre-generate a bundle of a
repository, and give a pointer to it to clients cloning the repository,
followed by another changegroup with the remainder. For significantly
big repositories, this could come as several base bundles with e.g. 10k
changesets, which, combined with checkpoints (not part of this change),
would prevent users with flaky networks from starting over any time
their connection fails.
While the server-side support for those features doesn't exist yet, it
is preferable to have client-side support for this early-on, allowing
experiments on servers only requiring a vanilla client with bundle2
enabled.
2014-10-17 04:57:05 +04:00
|
|
|
[255]
|
|
|
|
|
|
|
|
$ hg -R clone log -G
|
|
|
|
@ 2:5fddd98957c8 public Nicolas Dumazet <nicdumz.commits@gmail.com> C
|
|
|
|
|
|
|
|
|
o 1:42ccdea3bb16 public Nicolas Dumazet <nicdumz.commits@gmail.com> B
|
|
|
|
|
|
|
|
|
o 0:cd010b8cd998 public Nicolas Dumazet <nicdumz.commits@gmail.com> A
|
|
|
|
|
|
|
|
$ rm -rf clone
|
|
|
|
|
2015-06-08 22:55:40 +03:00
|
|
|
$ killdaemons.py
|