[PATCH 4 of 4 NEW-CONCEPT] track-tags: write all tag changes to a file

[Jun Wu]

Excerpts from Pierre-Yves David's message of 2017-04-07 14:52:44 +0200:
> 
> On 04/06/2017 08:18 PM, Jun Wu wrote:
> > Thanks for the clarification.
> >
> > My concern about performance is not writing the file, but calculating the
> > content to be written. I'd like to see more clarification about whether and
> > when this new code path triggers a full manifest read, since reading a flat
> > manifest is painfully slow on a large repo.
> 
> They is a cache for the changeset → fnode mapping. And this cache is 
> exchanged over the wire so I've not worried. Worst case we'll need a 
> pass to strengthen the cache warming at commit time (as part of the 
> "better use the cache before getting out of experimental"). So overall 
> we should not triggers full manifest read.
> 
> Does this address your concerns?

IIUC, you are assuming that in the transaction, when a new commit is
written, the manifest is known. However, that's not always the case. For
example, if I do "hg metaedit" (there could be more cases like this in the
future), it creates a new changelog node, but could reuse the manifest node
directly without reading that manfiest. That's what metadataonlyctx is used
for. Will you be able to avoid reading manifest to warm the cache in this
case?

> 
> Cheers,
>