[PATCH RFC V2] localrepo: don't reintroduce pruned tag entries when tagging

[Gregory Szorc]

> On Feb 25, 2015, at 6:55, Pierre-Yves David <pierre-yves.david at ens-lyon.org> wrote:
> 
> 
> 
>> On 02/25/2015 02:51 PM, Augie Fackler wrote:
>> On Wed, Feb 25, 2015 at 9:32 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>>> 
>>> 
>>>> On 02/10/2015 06:42 PM, Augie Fackler wrote:
>>>> 
>>>>> On Wed, Feb 04, 2015 at 10:10:54PM -0500, Matt Harbison wrote:
>>>>> 
>>>>> # HG changeset patch
>>>>> # User Matt Harbison <matt_harbison at yahoo.com>
>>>>> # Date 1412209593 14400
>>>>> #      Wed Oct 01 20:26:33 2014 -0400
>>>>> # Node ID de7c57345dfc58a49c25f97070b084e65b1cb0a0
>>>>> # Parent  e1dbe0b215ae137eec53ceb12440536d570a83d2
>>>>> localrepo: don't reintroduce pruned tag entries when tagging
>>>>> 
>>>>> If a commit and a followup tag commit are pruned, there are no references
>>>>> to it
>>>>> in any non obsolete version of .hgtags.  Without this change however, the
>>>>> next
>>>>> time a tag is added to another branch, the obsolete references are
>>>>> appended in
>>>>> .hgtags before the new entries for the current tag command.
>>>>> 
>>>>> The annotation to unfilter localrepo._tag() has been around since
>>>>> b3af182a1944.
>>>>> The log message for it mentions computing the tag cache though, so I'm
>>>>> not sure
>>>>> if this was misplaced?  It looks like branchmap was aware of filtering
>>>>> then, and
>>>>> now tracks a cache per view.
>>>> 
>>>> 
>>>> This looks reasonable to me. Queued.
>>> 
>>> 
>>> This looks highly unreasonable to me ;-)
>>> 
>>> The tags mechanism involves caching and needs to be aware of filtering level
>>> before we can move forward. Dropping the "unfiltered" decoration before that
>>> will likely cause obscure bug. Matt, description give me the impression that
>>> we need to dig deeper before dropping
>>> 
>>> 
>>> Can we drop/backout this?
>> 
>> I'm not sure what your objection is - do you think this introduces new bugs?
>> 
>> (It's queued largely because it resolves a bug, but I can be persuaded
>> that I'm missing something.)
> 
> From where I'm I read this patch as: the tags cache is always infiltered, this is a issue when using another view, we drop the filtering. As a result, the tag cache end up being computed for the first view asking for it and globally cached for all other view.
> 
> I would like someone to fix this or convince me I'm wrong before moving forward.

See issue 4550 and my proposed patch series for stable I submitted the other day.

I didn't even realize this patch was related until I read your replies!