Patchwork [1,of,4,RFC] chgcache: new experimental extension

login
register
mail settings
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

Jun Wu - Feb. 9, 2017, 1:41 a.m.
# 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.
Yuya Nishihara - Feb. 13, 2017, 1:46 p.m.
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.
Jun Wu - Feb. 13, 2017, 6:18 p.m.
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.
Yuya Nishihara - Feb. 14, 2017, 1:51 p.m.
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.
+"""