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

[Pierre-Yves David]

On 04/07/2017 03:50 PM, Jun Wu wrote:
> 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?

Yes, since we do not touch the manifest, we can reuse the entry from the 
originalctx.

In the general case, you either touch the '.hgtags' (and you know its 
value) or you don't and you can reuse the parent value.

Cheers,

-- 
Pierre-Yves David