Comment 4 for bug 295611

Revision history for this message
Jelmer Vernooij (jelmer) wrote : Re: NoSuchRevision: KnitPackRepository

It's definitely different from any of those.

From IRC yesterday:

22:42 < jelmer> lifeless, basically it's similar to the bug we looked at during the summer
22:43 * jelmer looks again
22:43 < jelmer> lifeless, sorry, it's actually related to ghosts
22:44 < jelmer> where "bzr diff" assumes that the revision info for the last-changed-revision of all files in the tree are present
22:49 < lifeless> jelmer: I can't parse that. Is a valid rephrasing 'the last-changed-revision is used as the key for the file text'?
22:49 < jelmer> lifeless, nope
22:50 < jelmer> lifeless, bzr diff prints the timestamp of the original text of a file and of the new revised one
22:51 < lifeless> with you so far
22:51 < jelmer> in order to obtain the timestamp for the old text, it uses the text revision and calls Repository.get_revision(text_revision)
22:51 < jelmer> if that text_revision happens to be a ghost, things break
22:51 < lifeless> ah
22:51 < lifeless> so there are some interactions here
22:52 -!- ia [n=ia@89.169.165.188] has joined #bzr
22:52 < lifeless> we really need to sit down and clean up the ghost handling once and for all
22:52 < lifeless> the interaction I'm thinking of is: we only copy text (id,X) when we copy revision X
22:52 < lifeless> so that repository isn't clonable by bzr at all anyhow
22:52 < lifeless> (as it currently stands)
22:53 < jelmer> that would break bzr-svn, which usually only pushes lhs revisions
22:53 < jelmer> that may contain references to texts introduced by rhs revisions
22:54 < jelmer> *those lhs revisions may contain references to texts introduced by rhs revisions
22:56 -!- oleavr [<email address hidden>] has joined #bzr
22:57 < lifeless> jelmer: 'does break'
22:58 < lifeless> jelmer: though I think I've mentioned before that having those references isn't strictly valid
22:58 < lifeless> under the current rules. And thus the need to fix this forever
22:59 < lifeless> the inventory work being done at the moment will open the door to handling this efficiently and preserving arbitrary revision text values, which would make the revision-being-absent a valid bug