[PATCH] hgweb: make refresh interval configurable

Gregory Szorc gregory.szorc at gmail.com
Sun Aug 23 00:55:00 CDT 2015


On Sat, Aug 22, 2015 at 9:16 PM, Anton Shestakov <av6 at dwimlabs.net> wrote:

> > # HG changeset patch
> > # User Gregory Szorc <gregory.szorc at gmail.com>
> > # Date 1440270190 25200
> > #      Sat Aug 22 12:03:10 2015 -0700
> > # Node ID 9b6d9cb5630fe4dcc5b2c32222ef0fd467976900
> > # Parent  d9d3d49c4cf77049d12920980e91bf8e4a4ecda2
> > hgweb: make refresh interval configurable
>
> I don't have much experience reviewing patches here, but since it's
> hgweb, I can give it a try.
>
> > hgwebdir refreshes the set of known repositories periodically. This
> > is necessary because refreshing on every request could add significant
> > request latency.
> >
> > More than once I've found myself wanting to tweak this interval at
> > Mozilla. I've also wanted the ability to always refresh (often when
> > writing tests for our replication setup).
> >
> > This patch makes the refresh interval configurable. Negative values
> > indicate to always refresh. The default is left unchanged.
> >
> > diff --git a/mercurial/help/config.txt b/mercurial/help/config.txt
> > --- a/mercurial/help/config.txt
> > +++ b/mercurial/help/config.txt
> > @@ -1751,8 +1751,16 @@ The full set of options is:
> >  ``push_ssl``
> >      Whether to require that inbound pushes be transported over SSL to
> >      prevent password sniffing. Default is True.
> >
> > +``refreshinterval``
> > +    How frequently directory listings re-scan the filesystem for new
> > +    repositories, in seconds. This is relevant when wildcards are
> > used
> > +    to define paths. Depending on how much filesystem traversal is
> > +    required, refreshing may negatively impact performance.
> > +
> > +    Default is 30. Negative values mean to always refresh.
>
> Is the +50% change from 20 to 30 a performance improvement? It's not
> clear why must the default change to make the interval configurable.
>
> I didn't mean to change this from 20 to 30. I must have fat fingered it.


> > +
> >  ``staticurl``
> >      Base URL to use for static files. If unset, static files (e.g.
> > the hgicon.png favicon) will be served by the CGI script itself. Use
> >      this setting to serve them directly with the HTTP server.
> > diff --git a/mercurial/hgweb/hgwebdir_mod.py
> > b/mercurial/hgweb/hgwebdir_mod.py ---
> > a/mercurial/hgweb/hgwebdir_mod.py +++
> > b/mercurial/hgweb/hgwebdir_mod.py @@ -78,19 +78,25 @@ def
> > geturlcgivars(baseurl, port):
> >      return name, str(port), path
> >
> >  class hgwebdir(object):
> > -    refreshinterval = 20
> > -
> >      def __init__(self, conf, baseui=None):
> >          self.conf = conf
> >          self.baseui = baseui
> > +        self.ui = None
> >          self.lastrefresh = 0
> >          self.motd = None
> >          self.refresh()
> >
> >      def refresh(self):
> > -        if self.lastrefresh + self.refreshinterval > time.time():
> > +        refreshinterval = 30
> > +        if self.ui:
> > +            refreshinterval = self.ui.configint('web',
> > 'refreshinterval',
> > +                                                refreshinterval)
> > +
> > +        # refreshinterval < 0 means to always refresh.
> > +        if (refreshinterval >= 0 and
> > +            self.lastrefresh + refreshinterval > time.time()):
> >              return
>
> It says that < 0 is always refresh, but what about 0? Looks like it
> also always refreshes, unless system clock goes backwards.
>
> For me 0 is special enough to think that 'refreshinterval = 0' also
> means a special case: either always refresh or never refresh. If the
> latter doesn't sound like a great idea (?), then I think it's good to
> make 0 mean the former.
>

Yeah, 0 should probably be "always refresh." It will likely be this way
anyway, as time.time() will almost certainly increment between requests.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150822/1d569571/attachment.html>


More information about the Mercurial-devel mailing list