corrupt deltas and dirstate corruption
John Arbash Meinel
john at arbash-meinel.com
Fri Jul 10 21:00:12 BST 2009
-----BEGIN PGP SIGNED MESSAGE-----
Robert Collins wrote:
> I've just landed (rev 4524) a patch which increases safety in using
> inventory deltas. I have plenty more to do in this area; but I'd like to
> encourage anyone debugging inventory or dirstate oddities to ensure they
> have merged rev 4524 into their tree: If the corruption is one of the
> types I've added checks for (e.g. parents that are files, or parents
> that don't exist) then a InconsistentDelta error will be raised. This
> should make things error earlier and not lead to corruption on disk.
> Additionally, if you *do* have a situation where corruption can be
> caused by applying an inventory delta, please make sure there are *two*
> bugs: one for the code thats creating a bad delta, and a second for the
> fact that the badness isn't detected.
> There are docs about this general concept and issue in the developer
> 'inventory' documentation.
So the one that came up recently was:
bzr add a
bzr mv a b
For some reason at that exact point the dirstate gets a bit odd, such that:
bzr commit -mtest
bzr mv b a
starts to fail.
My guess is that we are doing something funny with the newly added
record, when we rename it. (It should just get moved to yet-another
newly added record, but obviously that doesn't seem to be the case.)
Even weirder that 'bzr commit' does clean everything up so you start
from a clean slate (otherwise bzr mv b a wouldn't fail.) Again, it may
be the delta stuff, so that we have an "added but renamed" record at
'a', and committing the delta of 'add b', doesn't delete the 'a' record.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar