Failure upgrading bzr.dev repo from knits => packs using 1.6beta+ (bzr.dev)

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I still have a public repository in knits format, and I decided it was probably
time to upgrade it. I've run into 2 problems (sort of stemming from the same issue).

1) If the upgrade fails mid-way it leaves thing 'broken'. Specifically, it moves
.bzr/repository => .bzr/repository.backup and doesn't move it back. I'm partly
okay with this, as it allows some debugging, but it might be nice if there was a
rollback functionality on error.

2) The new 'insert_data_stream' code changes (getting rid of
VersionedFile.join()) means that we can no longer upgrade if we are missing some
of the revisions to files. Specifically, I hit this error:

~    to_weave.insert_record_stream(from_weave.get_record_stream(
~  File "/local/01/system/srv/bzr/public/mirrors/bzr.dev/bzrlib/knit.py", line
1151, in insert_record_stream
~    self)
RevisionNotPresent: Revision
{robertc at robertcollins.net-20050919044328-0205c679f3051340} not present
~ in
"KnitVersionedFile(file:///local/01/system/srv/bzr/public/branches/bzr/.bzr/repository/text%3Ajoin-branches.txt-20050309044946-f635037a889c0388)".

The problems here are:

~  a) I haven't been able to find a file named "text%3Ajoin..." anywhere.
~     I did track down that it actually meant the file:
~       knits/b8/join-branches.txt-20050309044946-f635037a889c0388.kndx
~     However, the choice of naming for pack repositories is quite confusing when
~     something breaks.

~  b) The "missing" revision *is* present in the source knit. My guess is that it
~     is a failure of the "get_data_stream_for_search()" functionality introduced
~     in bzr 1.6. I think we saw something like this when upgrading before, where
~     a text references a basis parent, which is *not* referenced by the
~     inventories. It didn't matter for '.join()' because .join() recomputed the
~     texts it needed to copy.



The upgrade succeeded with bzr-1.5 (in 12min on this machine), and then I assume
I'll need to 'bzr reconcile' to clean up the deltas like this. If that ends up
being the answer, I'm probably okay with it. We don't need to support broken
data through all versions from here on out. But it should certainly be
appropriately documented as the workaround for problems like this.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkhJSTgACgkQJdeBCYSNAAP2LgCeM+pJ6HbDBETRyR+RCespUOBC
mAQAoLxsv5Mm8c+yZm0iZ9zHaMjZNkTt
=bPkw
-----END PGP SIGNATURE-----