Tag caching, at last

[Dan Villiom Podlaski Christiansen]

On 10/07/2009, at 17.34, Greg Ward wrote:

>        # Optimization #1: if the first head == current tip, there have
>        # been new changesets since the cache was written.  All we need
>        # to do is read .hgtags from each head, and that's up to our
>        # caller (localrepo._findglobaltags()).
>        if goodheads and goodheads[0] == repo.changelog.tip():
>            #ui.debug("tag cache: tip not changed, so cache is up-to- 
> date\n")
>            return (goodheads, cachefnode)


I don't quite understand why this check is sufficient. If I understand  
the code and comment correctly, the logic goes something like this:  
Whenever tip is equal to our cached tip, our cache is correct. It  
would seem to me that the assumption doesn't hold. Both ‘rollback’ and  
‘strip’ can break this, especially if you combine them with the  
pushing and pulling of changesets.

Imagine two layouts like this:

      r1: A
       / \
    r2: B \
           \
         r3: C

    r1: A
     / \
    / r2: D
   /
r3: C

I can't quite think of simple use-case that would lead to scenarios  
such as this, but that doesn't mean it wouldn't happen: After all,  
users tend to do strange things :)

Wouldn't your code assume that all heads are the same in the two  
situations? It seems to me that checking whether all current heads are  
equal the cached heads is unavoidable.

(Or maybe I just got it all wrong…)

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
Url : http://selenic.com/pipermail/mercurial-devel/attachments/20090711/7fd9b57c/attachment.bin