Doesn't invalidate cache when ghosts filled

Bug #334615 reported by William Grant
2
Affects Status Importance Assigned to Milestone
loggerhead
Triaged
Low
Unassigned
loggerhead-breezy
Triaged
Low
Unassigned

Bug Description

Loggerhead needs a restart or tip change to detect that ghosts have been filled in a branch. Apparently it should be better than that.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I can't remember what this is about :/

I can believe there are all sorts of problems with mainline ghosts, but they are likely bigger than this issue.

Changed in loggerhead:
status: New → Incomplete
Revision history for this message
William Grant (wgrant) wrote :

There was a ghost right-hand parent in the latest revision when a branch was browsed. I then fixed the branch to fill that ghost, but LH didn't notice until the tip changed.

Changed in loggerhead:
status: Incomplete → New
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I don't really have a clue what to do about this.

Changed in loggerhead:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Max Kanat-Alexander (mkanat) wrote :

I'm pretty much just tempted to say "Won't Fix" here. Filled ghosts are going to be a pretty uncommon situation, and theoretically on many installations our branch cache will expire and we'll just rebuild things anyway. Fixing this in some other way would probably add a lot of complexity to the code, despite the fixes being only very rarely needed.

Changed in loggerhead:
importance: Medium → Low
Revision history for this message
Robert Collins (lifeless) wrote :

However the larger the install of loggerhead the more chance of running into this and the less familiar syadmins will be with individual branches (making diagnosis harder).

Changed in loggerhead:
status: Confirmed → Triaged
Revision history for this message
John A Meinel (jameinel) wrote :

I'm not entirely sure on the underlying issues, since this was posted a long time ago. I believe the issue is that loggerhead currently caches the whole ancestry when it sees the tip revision, and then doesn't invalidate that cache until the tip actually changes. (Even on restart, it will just reload it from the sqlite cache.)

the history-db work will change the effects a bit, but probably only to make it so that not even detecting a new tip will find the old ghost. (Because the new code doesn't search the whole ancestry whenever the tip changes, it just searches until it finds things it has already seen.)

history-db does explicitly track ghosts (there is a table of known ghosts). When a revision comes in that is a ghost, it could notice, and then rebuild the cache from scratch.

however, *noticing* the ghost filling requires some sort of search that would hit that revision. And we explicitly avoid doing that in stuff like bzrlib's fetch code (because it is slow with big ancestries). I think a nice 'catch-all' would be a 'rebuild-cache' button that people could get to. It might be slow, but it would allow you to manually say "you missed something old, rebuild".

Jelmer Vernooij (jelmer)
Changed in loggerhead-breezy:
status: New → Triaged
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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