[PATCH 3 of 3] tags: preserve filtered .hgtags filenodes in tags cache (issue4550)

[Pierre-Yves David]

On 02/28/2015 03:55 AM, Pierre-Yves David wrote:
>
>
> On 02/27/2015 07:11 PM, Gregory Szorc wrote:
>> On Fri, Feb 27, 2015 at 10:29 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
>> wrote:
>>
>>
>>
>>     On 02/24/2015 09:11 AM, Gregory Szorc wrote:
>>
>>         # HG changeset patch
>>         # User Gregory Szorc<gregory.szorc at gmail.com
>>         <mailto:gregory.szorc at gmail.com>>
>>         # Date 1424769075 28800
>>         #      Tue Feb 24 01:11:15 2015 -0800
>>         # Branch stable
>>         # Node ID 7f1904705c29ebe7de3874f2f03c42__e261ed1c96
>>         # Parent  7d72752b8da5bb2482e6eac47545a7__8ed3fff592
>>         tags: preserve filtered .hgtags filenodes in tags cache
>> (issue4550)
>>
>>
>>     It is clear that we need some filter awareness for tags.
>>
>>     However, the level of filter impact what are heads and therefore
>>     what file version-s- of .hgtags are considered. Therefore it seems
>>     strange to me that you have been able to build a solution that take
>>     filter into account -after- the tags have been computed.
>>
>>     So either:
>>     - I missed something in your patch which is quite complexe
>>     - I missed something in my understanding of the issue
>>     - There is something wrong with this patch.
>>
>>     Please find which of this options is true ;-)
>>
>>
>> The most important thing to understand about the tags cache is that it
>> is two caches in one. The first part is a mapping of head nodes to
>> .hgtags filenodes. The second part is a cache of the results of
>> resolving tags from the contents of all the .hgtags for a given set of
>> heads (a view).
>>
>> This (admittedly hacky) patch impacts just the first part, the filenode
>> cache. Instead of merely consulting the heads from the repo that was
>> passed in, we always expand context to include unfiltered heads as well.
>> There continues to exist multiple views of the resolved tags values, but
>> only the most recently-computed view is persisted in the cache. I
>> believe this "just works."
>
> So as far I understand, we cache both (A) revnum → .hgtags@<NODE>  and
> (B) mergetags(.hgtags@<node> for all <node> in heads).
>
> Until now, (A) also served as a cache for all heads. but this sets of
> heads are likely different for every "view" leading to invalid
> invalidation of both (A) and (B).
>
> Your patch focus on storing more revnum → .hgtags at node mapping in (A)
> relying on a post processing to filter out non-heads-in-current-view
> revnum before computing (B).
>
> (still as far as I understand), your patch helps by avoiding frequent
> manifest lookup. How does it really achieves it ??
>
>    - Is this because we frequently compute tags for unfiltered repo AND
> visible repoview?
>    OR
>    - Is keeping theses heads a good heuristic to keep useful heads
> arounds ?
>
> Similar question is: How do you ensure (B) is properly computed and
> invalidated. IF you cannot rely in  a mismatch between repo.heads() and
> content of (A), how do we invalid the cache ?
>
> Finally, shouldn't we include heads than the one for unfiltered and just
> the current view (likely "visible" but could be "served"). Repo may use
> a mix of "served" and "visible" for cache lookup and heads from other
> sub-view will likely be useful to cache.
>
>
> In all case, I'm not sure how it helps the other issue Matt Harbisson is
> trying to fix.

Any new on this? I'll probably drop it from patchwork no reply comes 
this way in the next two days.

-- 
Pierre-Yves David