[PATCH 2 of 2 remotefilelog] README: specify how to use memcached caching

Durham Goode durham at fb.com
Wed Oct 7 03:27:41 UTC 2015



On 9/28/15 11:02 PM, Mathias De Maré wrote:
> # HG changeset patch
> # User Mathias De Maré <mathias.demare at gmail.com>
> # Date 1443505828 -7200
> #      Tue Sep 29 07:50:28 2015 +0200
> # Node ID 4434e76fe9543a120404b5c261ae983511d4687d
> # Parent  e628ae9c436be1f13f0bef2247cbdc6abf6adc9a
> README: specify how to use memcached caching
>
> diff -r e628ae9c436b -r 4434e76fe954 README.md
> --- a/README.md	Tue Sep 29 07:48:58 2015 +0200
> +++ b/README.md	Tue Sep 29 07:50:28 2015 +0200
> @@ -38,7 +38,7 @@
>   * `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.
> +* `cacheprocess` - the external process that will handle the remote caching layer. If not set, all requests will go to the Mercurial server. To use memcached caching, you can set this to `path/to/remotefilelog/remotefilelog/cacheclient.py memcachedip:memcachedport memcachedprefix`
I've pushed the first patch in this series.

For the second patch, cacheclient.py was really meant to just be an 
example implementation.  I don't think it's robust or performant enough 
for us to want to advertise it for actual use.

If you've used it enough to prove it's better than falling back to the 
server (and that's it's robust enough in regular usage), I might 
consider adding it here.


More information about the Mercurial-devel mailing list