Does chg cache information?

Marcus Harnisch marcus.harnisch at verilab.com
Sun Jan 20 19:51:24 UTC 2019


Thanks for clarifying. Interesting background information. Not sure what
could have caused the observed behaviour, then. Anyway, I may investigate
if this happens again.

On Sun, Jan 20, 2019 at 2:03 AM Yuya Nishihara <yuya at tcha.org> wrote:

> On Sun, 20 Jan 2019 09:45:02 +0900, Yuya Nishihara wrote:
> > On Sat, 19 Jan 2019 20:13:09 +0100, Marcus Harnisch wrote:
> > > What do you mean by “chg daemon process is forked per connection”?
> Isn't it
> > > that invoking chg (client) checks for a daemon, starting it when
> necessary?
> > > Subsequent invokation of chg would detect an already running daemon.
> What
> > > constitutes a connection here? When I work in two different
> repositories on
> > > the same machine, the same chg daemon is going to used, no?
> >
> > Basically the same daemon waits new connection from chg (client), and the
> > daemon fork()s immediately after accept(). Then, a repository is loaded.
> >
> > The long-lived daemon process is just handling new connections from chg
> > clients. No repository data would be loaded by it.
>
> "No repository data loaded" isn't correct. A repository is loaded when
> the long-lived daemon starts, but it's different from the repository object
> which a forked worker process (so chg client) operates on.
>
> The repository object loaded by the long-lived daemon process is mostly
> unused. It's just for loading per-repository configuration into the daemon.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20190120/5fb20cf8/attachment-0002.html>


More information about the Mercurial mailing list