corrupt deltas and dirstate corruption

[John Arbash Meinel]

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

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.
> 
> -Rob

So the one that came up recently was:

bzr init
touch a
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.

John
=:->

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

iEYEARECAAYFAkpXncwACgkQJdeBCYSNAANE+QCcCrDNAQIC5MXzL1Jx861Rw1NF
vCMAnAnafFzHP+vkjWymH723OGEryN+p
=bu/D
-----END PGP SIGNATURE-----