| Submitter | Jun Wu |
|---|---|
| Date | Feb. 9, 2017, 1:41 a.m. |
| Message ID | <138f7ba58a70de961071.1486604461@x1c> |
| Download | mbox | patch |
| Permalink | /patch/18360/ |
| State | Changes Requested |
| Delegated to: | Yuya Nishihara |
| Headers | show |
Comments
On Wed, 8 Feb 2017 17:41:01 -0800, Jun Wu wrote: > # HG changeset patch > # User Jun Wu <quark@fb.com> > # Date 1486601732 28800 > # Wed Feb 08 16:55:32 2017 -0800 > # Node ID 138f7ba58a70de9610713b8bd55d1ba0ac468fa6 > # Parent a68510b69f413545722c086eaeb840dd5e8305b4 > # Available At https://bitbucket.org/quark-zju/hg-draft > # hg pull https://bitbucket.org/quark-zju/hg-draft -r 138f7ba58a70 > chgcache: new experimental extension > > This patch starts a new experimental extension - chgcache, which aims to > make chg stateful and be able to preload repo objects like the changelog, > the dirstate, the obsstore etc. > > The feature is being developed as a new extension, instead of directly at > core chg, because its APIs and implementation details are still subject to > change. I don't get why we're starting it as an extension. Can you elaborate? My random thoughts: a) because the feature is unstable => could be gated by config knob. b) for faster experiment of ideas => out-of-core extension might be better. c) to dump the whole implementation in case it turns out bad => maybe.
Excerpts from Yuya Nishihara's message of 2017-02-13 22:46:23 +0900: > On Wed, 8 Feb 2017 17:41:01 -0800, Jun Wu wrote: > > # HG changeset patch > > # User Jun Wu <quark@fb.com> > > # Date 1486601732 28800 > > # Wed Feb 08 16:55:32 2017 -0800 > > # Node ID 138f7ba58a70de9610713b8bd55d1ba0ac468fa6 > > # Parent a68510b69f413545722c086eaeb840dd5e8305b4 > > # Available At https://bitbucket.org/quark-zju/hg-draft > > # hg pull https://bitbucket.org/quark-zju/hg-draft -r 138f7ba58a70 > > chgcache: new experimental extension > > > > This patch starts a new experimental extension - chgcache, which aims to > > make chg stateful and be able to preload repo objects like the changelog, > > the dirstate, the obsstore etc. > > > > The feature is being developed as a new extension, instead of directly at > > core chg, because its APIs and implementation details are still subject to > > change. > > I don't get why we're starting it as an extension. Can you elaborate? > > My random thoughts: > > a) because the feature is unstable > => could be gated by config knob. > b) for faster experiment of ideas > => out-of-core extension might be better. > c) to dump the whole implementation in case it turns out bad > => maybe. I actually prefer doing it in core directly, but I don't have enough confidence on the final API. I guess it's fine as the users of the API would be limited. Another slight concern is putting all the API code in chgserver.py will make it much longer - probably also fine as long as different sections are separated by comments clearly.
On Mon, 13 Feb 2017 10:18:08 -0800, Jun Wu wrote: > Excerpts from Yuya Nishihara's message of 2017-02-13 22:46:23 +0900: > > On Wed, 8 Feb 2017 17:41:01 -0800, Jun Wu wrote: > > > # HG changeset patch > > > # User Jun Wu <quark@fb.com> > > > # Date 1486601732 28800 > > > # Wed Feb 08 16:55:32 2017 -0800 > > > # Node ID 138f7ba58a70de9610713b8bd55d1ba0ac468fa6 > > > # Parent a68510b69f413545722c086eaeb840dd5e8305b4 > > > # Available At https://bitbucket.org/quark-zju/hg-draft > > > # hg pull https://bitbucket.org/quark-zju/hg-draft -r 138f7ba58a70 > > > chgcache: new experimental extension > > > > > > This patch starts a new experimental extension - chgcache, which aims to > > > make chg stateful and be able to preload repo objects like the changelog, > > > the dirstate, the obsstore etc. > > > > > > The feature is being developed as a new extension, instead of directly at > > > core chg, because its APIs and implementation details are still subject to > > > change. > > > > I don't get why we're starting it as an extension. Can you elaborate? > > > > My random thoughts: > > > > a) because the feature is unstable > > => could be gated by config knob. > > b) for faster experiment of ideas > > => out-of-core extension might be better. > > c) to dump the whole implementation in case it turns out bad > > => maybe. > > I actually prefer doing it in core directly, but I don't have enough > confidence on the final API. I guess it's fine as the users of the API would > be limited. > > Another slight concern is putting all the API code in chgserver.py will make > it much longer - probably also fine as long as different sections are > separated by comments clearly. Sounds like we want a new chgcache module (not an extension.)
Patch
diff --git a/hgext/chgcache.py b/hgext/chgcache.py new file mode 100644 --- /dev/null +++ b/hgext/chgcache.py @@ -0,0 +1,11 @@ +# chgcache.py - add repo-level preloading functionality to chg +# +# Copyright 2017 Facebook, Inc. +# +# This software may be used and distributed according to the terms of the +# GNU General Public License version 2 or any later version. +"""repo-level caching for chg (EXPERIMENTAL) + +With this extension installed, Mercurial running with chg will be able to cache +repo objects to further reduce start-up time. +"""