[PATCH] dirstate: rebuild should update dirstate properly

[Yuya Nishihara]

On Tue, 30 Aug 2016 21:34:01 +0000, Mateusz Kwapich wrote:
> On 8/28/16, 3:01 PM, "Yuya Nishihara" <youjah at gmail.com on behalf of yuya at tcha.org> wrote:
>     > Updating dirstate by simply adding and dropping files from self._map doesn't
>     > keep the other maps updated (think: _dirs, _copymap, _foldmap, _nonormalset)
>     > thus introducing cache inconsistency.
>     
>     I think that's why rebuild() calls self.clear(). IIRC, I've pointed out that it
>     would be wrong to skip the whole clear() step when changedfiles is not None.
> 
> Clear doesn’t invalidate all the caches – for example it doesn’t touch filefoldmap or
> Dirfoldmap. Also: why would we clear those caches instead of updating them?

Perhaps that's a bug introduced when file/dirfoldmap were added.

>     > --- a/tests/test-rebuildstate.t
>     > +++ b/tests/test-rebuildstate.t
>     > @@ -48,8 +48,8 @@ basic test for hg debugrebuildstate
>     >  state dump after
>     >  
>     >    $ hg debugstate --nodates | sort
>     > -  n 644         -1 set                 bar
>     > -  n 644         -1 set                 foo
>     > +  n   0         -1 unset               bar
>     > +  n   0         -1 unset               foo
>     
>     This seems wrong. debugrebuilddirstate is documented as "dirstate will be
>     set to the files of the given revision. The actual working directory content
>     [...] is not considered."
> 
> Yeah. It still doesn’t consider the working directory contents, still contains the same files
> and all entries will still be checked at the next status call. Only things that are different in
> this output are file permissions and mtime which are not stored in the commit itself.

My concern is there might be a reason to fully populate a dirstate by
"hg debugrebuilddirstate" because the result is explicitly tested by
"hg debugstate". I hope my concern isn't a thing, but I'm not sure.