KnitRepository.insert_data_stream() copies data in improper order
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Fix Released
|
Critical
|
Unassigned |
Bug Description
Looking at the implementation of "Repository.
This is valid for pack repositories, because we will abort the whole pack if it is incomplete. But for Knit repositories if it is interrupted, then Bazaar believes everything was properly copied (because we used "if the Revision is present then the Inventory is, and if the Inventory is, then all Texts are.) We still assume that with packs, but when it is violated we don't add it to the list of pack-names.
This is critical as it makes ^C during a bzr+ssh:// push of knit repositories corrupt the target repo.
Changed in bzr: | |
importance: | Undecided → Critical |
status: | New → Triaged |
Changed in bzr: | |
status: | Won't Fix → Fix Released |
Someone should confirm the output stream sequence. My cursory double check seems to say that the data stream sent by the server should be reasonable.
Specifically, get_data_stream seems to be layered on top of Repository. item_keys_ introduced_ by() whose default implementation seems to stream the inventories after the file texts.
However, we still have some real-world cases where it seems to have streamed in the wrong order.
My quick test of creating a --knit with bzr.dev, and then committing a couple and manually stepping the 'get_data_stream()' iterator also says that we copy file texts first.
So we still need to figure out how ^C during a push could copy the inventories, but not the file texts.