Bazaar

hashcache is invalidated when a file's containing directory is renamed

Bug #150820 reported by Martin Pool
2
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

Revision history for this message
John A Meinel (jameinel) wrote :

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)

Revision history for this message
Robert Collins (lifeless) wrote :

I'm pretty sure this is fixed at the dirstate level with update_via_delta; higher level API's may not be using htat across the board yet.

Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.