hashcache is invalidated when a file's containing directory is renamed
Bug #150820 reported by
Martin Pool
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Wishlist
|
Unassigned |
Bug Description
affects bzr
status confirmed
importance wishlist
Renaming a directory changes all of the dirstate records, and probably
loses their hashcache information. It would be nice not to lose them.
We could conceivable keep the hashcache just as a dictionary from stat
info to hash, though that would lose the advantage of easy access inline
with the dirstate.
--
Martin
--
Martin
tags: | added: check-for-breezy |
To post a comment you must log in.
Going along with this, all the rename logic is actually based around 'set_state_ from_inventory' , rather than directly changing the dirstate. Well, sometimes. "rename_one" is not implemented directly, but "move" is. So if you move files into a subdir (bzr mv X Y Z dir/) it will probably maintain state in a reasonable fashion. If you rename a file "bzr mv foo bar" then it will likely lose it.
What we really need is a superset interface to both rename_one and move, that can be implemented 1 time, and then rename_one and move can just call that. (I think WT3 has an internal function like this, but WT4 does not)