Does chg cache information?

[Marcus Harnisch]

Thanks for the debug tip. I'll keep that in mind for when I get into such
an issue again.
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?

On Sat, Jan 19, 2019 at 12:44 PM Yuya Nishihara <yuya at tcha.org> wrote:

> On Fri, 18 Jan 2019 22:04:20 +0100, Marcus Harnisch wrote:
> > To make my life a little less miserable I wrote a semi-automatic bridge
> > between Hg and Clearcase (CC) in the form of a bunch of scripts. The Hg
> > repo resides in a CC view as unversioned object. To speed up my scripts
> > (should be an extension really...) I have switched to chg which improves
> > performance considerably. In a second CC view with its own Hg repo I am
> > tracking other people's changes. A bit like a vendor branch. Very
> primitive
> > indeed.
> > Recently I ran into the odd situation that one Hg repo appeared to have
> > lost revisions while the files' contents were up-to-date but shown as
> > modified. As if .hg had been restored from an old backup. Read-only
> > experimenting in both repos returned inconsistent results. After a bit of
> > head scratching I noticed that both shells with their respective CC views
> > and corresponding Hg repos were executed on the same machine, thus
> sharing
> > a chg process, which is such an unlikely situation here that I hadn't
> even
> > thought of that before. The thing is that in different CC views,
> identical
> > paths point to different file objects. After making sure that both views
> > are accessed on different machines, i.e. different chg instances,
> > everything is fine again.
> >
> > Is it possible that chg caches information about paths and may have used
> > the wrong information when accessed from the other repo? Not looking for
> a
> > fix from your end, just curious if I am on the right track with my
> > assumption.
>
> It's unlikely that chg caches repository data. chg daemon process is forked
> per connection, and a repository object is loaded after fork(). However,
> if an extension does weird thing in uisetup()/extsetup(), the result may
> persist.
>
> Since 4.9rc released today, you can dump internal events to log file. It
> might help debugging the issue.
>
>   [cmdserver]
>   log = /path/to/server.log
>   # events to track (default: chgserver, cmdserver, repocache)
>   track-log = *
>
> (Note: repocache is new experimental feature and is disabled by default.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20190119/e7effef1/attachment-0002.html>