##// END OF EJS Templates
compression: introduce a `storage.revlog.zlib.level` configuration...
compression: introduce a `storage.revlog.zlib.level` configuration This option control the zlib compression level used when compression revlog chunk. This is also a good excuse to pave the way for a similar configuration option for the zstd compression engine. Having a dedicated option for each compression algorithm is useful because they don't support the same range of values. Using a higher zlib compression impact CPU consumption at compression time, but does not directly affected decompression time. However dealing with small compressed chunk can directly help decompression and indirectly help other revlog logic. I ran some basic test on repositories using different level. I am using the mercurial, pypy, netbeans and mozilla-central clone from our benchmark suite. All tested repository use sparse-revlog and got all their delta recomputed. The different compression level has a small effect on the repository size (about 10% variation in the total range). My quick analysis is that revlog mostly store small delta, that are not affected by the compression level much. So the variation probably mostly comes from better compression of the snapshots revisions, and snapshot revision only represent a small portion of the repository content. I also made some basic timings measurements. The "read" timings are gathered using simple run of `hg perfrevlogrevisions`, the "write" timings using `hg perfrevlogwrite` (restricted to the last 5000 revisions for netbeans and mozilla central). The timings are gathered on a generic machine, (not one of our performance locked machine), so small variation might not be meaningful. However large trend remains relevant. Keep in mind that these numbers are not pure compression/decompression time. They also involve the full revlog logic. In particular the difference in chunk size has an impact on the delta chain structure, affecting performance when writing or reading them. On read/write performance, the compression level has a bigger impact. Counter-intuitively, the higher compression levels improve "write" performance for the large repositories in our tested setting. Maybe because the last 5000 delta chain end up having a very different shape in this specific spot? Or maybe because of a more general trend of better delta chains thanks to the smaller chunk and snapshot. This series does not intend to change the default compression level. However, these result call for a deeper analysis of this performance difference in the future. Full data ========= repo level .hg/store size 00manifest.d read write ---------------------------------------------------------------- mercurial 1 49,402,813 5,963,475 0.170159 53.250304 mercurial 6 47,197,397 5,875,730 0.182820 56.264320 mercurial 9 47,121,596 5,849,781 0.189219 56.293612 pypy 1 370,830,572 28,462,425 2.679217 460.721984 pypy 6 340,112,317 27,648,747 2.768691 467.537158 pypy 9 338,360,736 27,639,003 2.763495 476.589918 netbeans 1 1,281,847,810 165,495,457 122.477027 520.560316 netbeans 6 1,205,284,353 159,161,207 139.876147 715.930400 netbeans 9 1,197,135,671 155,034,586 141.620281 678.297064 mozilla 1 2,775,497,186 298,527,987 147.867662 751.263721 mozilla 6 2,596,856,420 286,597,671 170.572118 987.056093 mozilla 9 2,587,542,494 287,018,264 163.622338 739.803002
marmoute -
r42210:1fac9b93 default
Show More
Name Size Modified Last Commit Author
/ hgext / remotefilelog
README.md Loading ...
__init__.py Loading ...
basepack.py Loading ...
basestore.py Loading ...
connectionpool.py Loading ...
constants.py Loading ...
contentstore.py Loading ...
datapack.py Loading ...
debugcommands.py Loading ...
extutil.py Loading ...
fileserverclient.py Loading ...
historypack.py Loading ...
metadatastore.py Loading ...
remotefilectx.py Loading ...
remotefilelog.py Loading ...
remotefilelogserver.py Loading ...
repack.py Loading ...
shallowbundle.py Loading ...
shallowrepo.py Loading ...
shallowstore.py Loading ...
shallowutil.py Loading ...
shallowverifier.py Loading ...

remotefilelog

The remotefilelog extension allows Mercurial to clone shallow copies of a repository such that all file contents are left on the server and only downloaded on demand by the client. This greatly speeds up clone and pull performance for repositories that have long histories or that are growing quickly.

In addition, the extension allows using a caching layer (such as memcache) to serve the file contents, thus providing better scalability and reducing server load.

Installing

NOTE: See the limitations section below to check if remotefilelog will work for your use case.

remotefilelog can be installed like any other Mercurial extension. Download the source code and add the remotefilelog subdirectory to your hgrc:

[extensions]
remotefilelog=path/to/remotefilelog/remotefilelog

Configuring

Server

  • server (required) - Set to 'True' to indicate that the server can serve shallow clones.
  • serverexpiration - The server keeps a local cache of recently requested file revision blobs in .hg/remotefilelogcache. This setting specifies how many days they should be kept locally. Defaults to 30.

An example server configuration:

[remotefilelog]
server = True
serverexpiration = 14

Client

  • cachepath (required) - the location to store locally cached file revisions
  • cachelimit - the maximum size of the cachepath. By default it's 1000 GB.
  • cachegroup - the default unix group for the cachepath. Useful on shared systems so multiple users can read and write to the same cache.
  • cacheprocess - the external process that will handle the remote caching layer. If not set, all requests will go to the Mercurial server.
  • fallbackpath - the Mercurial repo path to fetch file revisions from. By default it uses the paths.default repo. This setting is useful for cloning from shallow clones and still talking to the central server for file revisions.
  • includepattern - a list of regex patterns matching files that should be kept remotely. Defaults to all files.
  • excludepattern - a list of regex patterns matching files that should not be kept remotely and should always be downloaded.
  • pullprefetch - a revset of commits whose file content should be prefetched after every pull. The most common value for this will be '(bookmark() + head()) & public()'. This is useful in environments where offline work is common, since it will enable offline updating to, rebasing to, and committing on every head and bookmark.

An example client configuration:

[remotefilelog]
cachepath = /dev/shm/hgcache
cachelimit = 2 GB

Using as a largefiles replacement

remotefilelog can theoretically be used as a replacement for the largefiles extension. You can use the includepattern setting to specify which directories or file types are considered large and they will be left on the server. Unlike the largefiles extension, this can be done without converting the server repository. Only the client configuration needs to specify the patterns.

The include/exclude settings haven't been extensively tested, so this feature is still considered experimental.

An example largefiles style client configuration:

[remotefilelog]
cachepath = /dev/shm/hgcache
cachelimit = 2 GB
includepattern = *.sql3
  bin/*

Usage

Once you have configured the server, you can get a shallow clone by doing:

hg clone --shallow ssh://server//path/repo

After that, all normal mercurial commands should work.

Occasionly the client or server caches may grow too big. Run hg gc to clean up the cache. It will remove cached files that appear to no longer be necessary, or any files that exceed the configured maximum size. This does not improve performance; it just frees up space.

Limitations

  1. The extension must be used with Mercurial 3.3 (commit d7d08337b3f6) or higher (earlier versions of the extension work with earlier versions of Mercurial though, up to Mercurial 2.7).

  2. remotefilelog has only been tested on linux with case-sensitive filesystems. It should work on other unix systems but may have problems on case-insensitive filesystems.

  3. remotefilelog only works with ssh based Mercurial repos. http based repos are currently not supported, though it shouldn't be too difficult for some motivated individual to implement.

  4. Tags are not supported in completely shallow repos. If you use tags in your repo you will have to specify excludepattern=.hgtags in your client configuration to ensure that file is downloaded. The include/excludepattern settings are experimental at the moment and have yet to be deployed in a production environment.

  5. A few commands will be slower. hg log <filename> will be much slower since it has to walk the entire commit history instead of just the filelog. Use hg log -f <filename> instead, which remains very fast.

Contributing

Patches are welcome as pull requests, though they will be collapsed and rebased to maintain a linear history. Tests can be run via:

cd tests
./run-tests --with-hg=path/to/hgrepo/hg

We (Facebook) have to ask for a "Contributor License Agreement" from someone who sends in a patch or code that we want to include in the codebase. This is a legal requirement; a similar situation applies to Apache and other ASF projects.

If we ask you to fill out a CLA we'll direct you to our online CLA page where you can complete it easily. We use the same form as the Apache CLA so that friction is minimal.

License

remotefilelog is made available under the terms of the GNU General Public License version 2, or any later version. See the COPYING file that accompanies this distribution for the full text of the license.