© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Just to follow up, as Kiko asked me to poke my head in here.
To summarize the problem: There is a revision, which says that it did *not* modify a text, but that you should use the version of the text available in one of its (ancestral) parents. That parent is actually a ghost, which means we don't have information for it, such as an inventory that we can use to recognize the text to be copied.
In 'knit' format, Bazaar would keep track of each files ancestry separately, and didn't realize that the text wasn't referenced from the appropriate inventory. So at "fetch" time, it just grabbed everything it didn't have that was in the ancestry of the revisions it was interested in.
The new fetch code says "give me all texts for *these* revisions".
It is arguably a bug in the converter, that it decided to assign the text to a revision it didn't know anything about.
There are 2 possible "easy" fixes (one easier than the other, but more "evil")
1) Write some code (possibly part of reconcile) that fixes up these inventories, and changes the 'last-modified' field. Instead of having it reference the "ghost" revision, it will just say that the file was modified in THIS (since it differs from all other *present* parents). And then insert the text with that revision.
This requires rewriting specific inventories, and won't propagate, etc.
2) Generate a "fake" revision with the right information. Specifically, we need it to have a revision id which matches, and an inventory which references the file in question.
This could probably be done in about 5 minutes. (If I was doing it, I would take the information for the "broken" revision, copy it, modify the 2 attributes, and push that into the repository.)
(2) is evil, but easy and fast. You are injecting false information into the system. If the real information is "out-there" and comes in contact with this code, the results are *undefined*. In this particular case, I don't think it is a problem. If you had access to that revision, you could just convert it, and then it would just join into the ancestry without a problem. As it seems to be "truly gone" we can create an artificial one without them meeting eachother.
If you are okay with (2), I can do it, and probably give you a bundle to merge. At which point your repository will be 'infected" with the artificial revision and cloning from it will succeed without complaint. Future clones from this repository will also stay infected.
Merging this repository probably will not, as we don't fill in ghosts as a side-effect anymore.