Mercurial > hg
view tests/test-fetch.t @ 26623:5a95fe44121d
clonebundles: support for seeding clones from pre-generated bundles
Cloning can be an expensive operation for servers because the server
generates a bundle from existing repository data at request time. For
a large repository like mozilla-central, this consumes 4+ minutes
of CPU time on the server. It also results in significant network
utilization. Multiplied by hundreds or even thousands of clients and
the ensuing load can result in difficulties scaling the Mercurial server.
Despite generation of bundles being deterministic until the next
changeset is added, the generation of bundles to service a clone request
is not cached. Each clone thus performs redundant work. This is
wasteful.
This patch introduces the "clonebundles" extension and related
client-side functionality to help alleviate this deficiency. The
client-side feature is behind an experimental flag and is not enabled by
default.
It works as follows:
1) Server operator generates a bundle and makes it available on a
server (likely HTTP).
2) Server operator defines the URL of a bundle file in a
.hg/clonebundles.manifest file.
3) Client `hg clone`ing sees the server is advertising bundle URLs.
4) Client fetches and applies the advertised bundle.
5) Client performs equivalent of `hg pull` to fetch changes made since
the bundle was created.
Essentially, the server performs the expensive work of generating a
bundle once and all subsequent clones fetch a static file from
somewhere. Scaling static file serving is a much more manageable
problem than scaling a Python application like Mercurial. Assuming your
repository grows less than 1% per day, the end result is 99+% of CPU
and network load from clones is eliminated, allowing Mercurial servers
to scale more easily. Serving static files also means data can be
transferred to clients as fast as they can consume it, rather than as
fast as servers can generate it. This makes clones faster.
Mozilla has implemented similar functionality of this patch on
hg.mozilla.org using a custom extension. We are hosting bundle files in
Amazon S3 and CloudFront (a CDN) and have successfully offloaded
>1 TB/day in data transfer from hg.mozilla.org, freeing up significant
bandwidth and CPU resources. The positive impact has been stellar and
I believe it has proved its value to be included in Mercurial core. I
feel it is important for the client-side support to be enabled in core
by default because it means that clients will get faster, more reliable
clones and will enable server operators to reduce load without
requiring any client-side configuration changes (assuming clients are
up to date, of course).
The scope of this feature is narrowly and specifically tailored to
cloning, despite "serve pulls from pre-generated bundles" being a valid
and useful feature. I would eventually like for Mercurial servers to
support transferring *all* repository data via statically hosted files.
You could imagine a server that siphons all pushed data to bundle files
and instructs clients to apply a stream of bundles to reconstruct all
repository data. This feature, while useful and powerful, is
significantly more work to implement because it requires the server
component have awareness of discovery and a mapping of which changesets
are in which files. Full, clone bundles, by contrast, are much simpler.
The wire protocol command is named "clonebundles" instead of something
more generic like "staticbundles" to leave the door open for a new, more
powerful and more generic server-side component with minimal backwards
compatibility implications. The name "bundleclone" is used by Mozilla's
extension and would cause problems since there are subtle differences
in Mozilla's extension.
Mozilla's experience with this idea has taught us that some form of
"content negotiation" is required. Not all clients will support all
bundle formats or even URLs (advanced TLS requirements, etc). To ensure
the highest uptake possible, a server needs to advertise multiple
versions of bundles and clients need to be able to choose the most
appropriate from that list one. The "attributes" in each
server-advertised entry facilitate this filtering and sorting. Their
use will become apparent in subsequent patches.
Initial inspiration and credit for the idea of cloning from static files
belongs to Augie Fackler and his "lookaside clone" extension proof of
concept.
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Fri, 09 Oct 2015 11:22:01 -0700 |
parents | 701df761aa94 |
children | e01bd7385f4f |
line wrap: on
line source
#require serve $ echo "[extensions]" >> $HGRCPATH $ echo "fetch=" >> $HGRCPATH test fetch with default branches only $ hg init a $ echo a > a/a $ hg --cwd a commit -Ama adding a $ hg clone a b updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone a c updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo b > a/b $ hg --cwd a commit -Amb adding b $ hg --cwd a parents -q 1:d2ae7f538514 should pull one change $ hg --cwd b fetch ../a pulling from ../a searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg --cwd b parents -q 1:d2ae7f538514 $ echo c > c/c $ hg --cwd c commit -Amc adding c $ hg clone c d updating to branch default 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone c e updating to branch default 2 files updated, 0 files merged, 0 files removed, 0 files unresolved We cannot use the default commit message if fetching from a local repo, because the path of the repo will be included in the commit message, making every commit appear different. should merge c into a $ hg --cwd c fetch -d '0 0' -m 'automated merge' ../a pulling from ../a searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (+1 heads) updating to 2:d2ae7f538514 1 files updated, 0 files merged, 1 files removed, 0 files unresolved merging with 1:d36c0562f908 1 files updated, 0 files merged, 0 files removed, 0 files unresolved new changeset 3:a323a0c43ec4 merges remote changes with local $ ls c a b c $ hg --cwd a serve -a localhost -p $HGPORT -d --pid-file=hg.pid $ cat a/hg.pid >> "$DAEMON_PIDS" fetch over http, no auth (this also tests that editor is invoked if '--edit' is specified) $ HGEDITOR=cat hg --cwd d fetch --edit http://localhost:$HGPORT/ pulling from http://localhost:$HGPORT/ searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (+1 heads) updating to 2:d2ae7f538514 1 files updated, 0 files merged, 1 files removed, 0 files unresolved merging with 1:d36c0562f908 1 files updated, 0 files merged, 0 files removed, 0 files unresolved Automated merge with http://localhost:$HGPORT/ HG: Enter commit message. Lines beginning with 'HG:' are removed. HG: Leave message empty to abort commit. HG: -- HG: user: test HG: branch merge HG: branch 'default' HG: changed c new changeset 3:* merges remote changes with local (glob) $ hg --cwd d tip --template '{desc}\n' Automated merge with http://localhost:$HGPORT/ $ hg --cwd d status --rev 'tip^1' --rev tip A c $ hg --cwd d status --rev 'tip^2' --rev tip A b fetch over http with auth (should be hidden in desc) (this also tests that editor is not invoked if '--edit' is not specified, even though commit message is not specified explicitly) $ HGEDITOR=cat hg --cwd e fetch http://user:password@localhost:$HGPORT/ pulling from http://user:***@localhost:$HGPORT/ searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (+1 heads) updating to 2:d2ae7f538514 1 files updated, 0 files merged, 1 files removed, 0 files unresolved merging with 1:d36c0562f908 1 files updated, 0 files merged, 0 files removed, 0 files unresolved new changeset 3:* merges remote changes with local (glob) $ hg --cwd e tip --template '{desc}\n' Automated merge with http://localhost:$HGPORT/ $ hg clone a f updating to branch default 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone a g updating to branch default 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo f > f/f $ hg --cwd f ci -Amf adding f $ echo g > g/g $ hg --cwd g ci -Amg adding g $ hg clone -q f h $ hg clone -q g i should merge f into g $ hg --cwd g fetch -d '0 0' --switch -m 'automated merge' ../f pulling from ../f searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (+1 heads) 0 files updated, 0 files merged, 0 files removed, 0 files unresolved merging with 3:6343ca3eff20 1 files updated, 0 files merged, 0 files removed, 0 files unresolved new changeset 4:f7faa0b7d3c6 merges remote changes with local $ rm i/g should abort, because i is modified $ hg --cwd i fetch ../h abort: uncommitted changes [255] test fetch with named branches $ hg init nbase $ echo base > nbase/a $ hg -R nbase ci -Am base adding a $ hg -R nbase branch a marked working directory as branch a (branches are permanent and global, did you want a bookmark?) $ echo a > nbase/a $ hg -R nbase ci -m a $ hg -R nbase up -C 0 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R nbase branch b marked working directory as branch b $ echo b > nbase/b $ hg -R nbase ci -Am b adding b pull in change on foreign branch $ hg clone nbase n1 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone nbase n2 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R n1 up -C a 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo aa > n1/a $ hg -R n1 ci -m a1 $ hg -R n2 up -C b 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R n2 fetch -m 'merge' n1 pulling from n1 searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files parent should be 2 (no automatic update) $ hg -R n2 parents --template '{rev}\n' 2 $ rm -fr n1 n2 pull in changes on both foreign and local branches $ hg clone nbase n1 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone nbase n2 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R n1 up -C a 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo aa > n1/a $ hg -R n1 ci -m a1 $ hg -R n1 up -C b 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo bb > n1/b $ hg -R n1 ci -m b1 $ hg -R n2 up -C b 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R n2 fetch -m 'merge' n1 pulling from n1 searching for changes adding changesets adding manifests adding file changes added 2 changesets with 2 changes to 2 files 1 files updated, 0 files merged, 0 files removed, 0 files unresolved parent should be 4 (fast forward) $ hg -R n2 parents --template '{rev}\n' 4 $ rm -fr n1 n2 pull changes on foreign (2 new heads) and local (1 new head) branches with a local change $ hg clone nbase n1 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone nbase n2 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R n1 up -C a 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo a1 > n1/a $ hg -R n1 ci -m a1 $ hg -R n1 up -C b 2 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo bb > n1/b $ hg -R n1 ci -m b1 $ hg -R n1 up -C 1 1 files updated, 0 files merged, 1 files removed, 0 files unresolved $ echo a2 > n1/a $ hg -R n1 ci -m a2 created new head $ hg -R n2 up -C b 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo change >> n2/c $ hg -R n2 ci -A -m local adding c $ hg -R n2 fetch -d '0 0' -m 'merge' n1 pulling from n1 searching for changes adding changesets adding manifests adding file changes added 3 changesets with 3 changes to 2 files (+2 heads) updating to 5:3c4a837a864f 1 files updated, 0 files merged, 1 files removed, 0 files unresolved merging with 3:1267f84a9ea5 1 files updated, 0 files merged, 0 files removed, 0 files unresolved new changeset 7:2cf2a1261f21 merges remote changes with local parent should be 7 (new merge changeset) $ hg -R n2 parents --template '{rev}\n' 7 $ rm -fr n1 n2 pull in changes on foreign (merge of local branch) and local (2 new heads) with a local change $ hg clone nbase n1 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone nbase n2 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R n1 up -C a 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg -R n1 merge b 1 files updated, 0 files merged, 0 files removed, 0 files unresolved (branch merge, don't forget to commit) $ hg -R n1 ci -m merge $ hg -R n1 up -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo c > n1/a $ hg -R n1 ci -m c $ hg -R n1 up -C 2 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo cc > n1/a $ hg -R n1 ci -m cc created new head $ hg -R n2 up -C b 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo change >> n2/b $ hg -R n2 ci -A -m local $ hg -R n2 fetch -m 'merge' n1 pulling from n1 searching for changes adding changesets adding manifests adding file changes added 3 changesets with 2 changes to 1 files (+2 heads) not merging with 1 other new branch heads (use "hg heads ." and "hg merge" to merge them) [1] parent should be 3 (fetch did not merge anything) $ hg -R n2 parents --template '{rev}\n' 3 $ rm -fr n1 n2 pull in change on different branch than dirstate $ hg init n1 $ echo a > n1/a $ hg -R n1 ci -Am initial adding a $ hg clone n1 n2 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo b > n1/a $ hg -R n1 ci -m next $ hg -R n2 branch topic marked working directory as branch topic (branches are permanent and global, did you want a bookmark?) $ hg -R n2 fetch -m merge n1 abort: working directory not at branch tip (use "hg update" to check out branch tip) [255] parent should be 0 (fetch did not update or merge anything) $ hg -R n2 parents --template '{rev}\n' 0 $ rm -fr n1 n2 test fetch with inactive branches $ hg init ib1 $ echo a > ib1/a $ hg --cwd ib1 ci -Am base adding a $ hg --cwd ib1 branch second marked working directory as branch second (branches are permanent and global, did you want a bookmark?) $ echo b > ib1/b $ hg --cwd ib1 ci -Am onsecond adding b $ hg --cwd ib1 branch -f default marked working directory as branch default $ echo c > ib1/c $ hg --cwd ib1 ci -Am newdefault adding c created new head $ hg clone ib1 ib2 updating to branch default 3 files updated, 0 files merged, 0 files removed, 0 files unresolved fetch should succeed $ hg --cwd ib2 fetch ../ib1 pulling from ../ib1 searching for changes no changes found $ rm -fr ib1 ib2 test issue1726 $ hg init i1726r1 $ echo a > i1726r1/a $ hg --cwd i1726r1 ci -Am base adding a $ hg clone i1726r1 i1726r2 updating to branch default 1 files updated, 0 files merged, 0 files removed, 0 files unresolved $ echo b > i1726r1/a $ hg --cwd i1726r1 ci -m second $ echo c > i1726r2/a $ hg --cwd i1726r2 ci -m third $ HGMERGE=true hg --cwd i1726r2 fetch ../i1726r1 pulling from ../i1726r1 searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files (+1 heads) updating to 2:7837755a2789 1 files updated, 0 files merged, 0 files removed, 0 files unresolved merging with 1:d1f0c6c48ebd merging a 0 files updated, 1 files merged, 0 files removed, 0 files unresolved new changeset 3:* merges remote changes with local (glob) $ hg --cwd i1726r2 heads default --template '{rev}\n' 3 test issue2047 $ hg -q init i2047a $ cd i2047a $ echo a > a $ hg -q ci -Am a $ hg -q branch stable $ echo b > b $ hg -q ci -Am b $ cd .. $ hg -q clone -r 0 i2047a i2047b $ cd i2047b $ hg fetch ../i2047a pulling from ../i2047a searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files $ cd ..