Inconsistent deltas created when commiting and an implicit delete has happened

[Spencer E. Chastain]

This bug occurs when I (1) pull a child directory up (2) remove the old parent directory and (3) remove a file under the child directory (that was elevated in the tree by the move)

I believe this has severely broken a branch on a private network that I cannot extract data from. However, reproducing the steps in a simple case (such as below) does not break a branch, per se, but it does create an error and seem to put the branch into a weird state between revision 2 and 3.

Either way, it's a problem, and I think it may be creating larger problems in trees where I have been doing much more of this kind of activity.

$ bzr init test
$ cd test
$ mkdir -p del/sub
$ touch del/sub/a
$ touch del/sub/b
$ bzr add
added del
added del/sub
added del/sub/a
added del/sub/b
$ bzr commit -m "setup"
Committing to: /home/sechastain/workspace/test/
added del
added del/sub
added del/sub/a
added del/sub/b
Committed revision 1.

$ bzr mv del/sub sub
del/sub => sub
$ rmdir del
$ rm sub/b

$ bzr commit -m "break"
Committing to: /home/sechastain/workspace/test/
missing del
renamed del/sub => sub
missing sub/b
deleted del
deleted del/sub/b
bzr: ERROR: dirstate: inconsistent delta, with tree 0. 'del/sub/b' 'b-20080130013519-454g97znowa6cvkh-4'

$ bzr status
removed:
  del/
  del/sub/b
renamed:
  del/sub => sub

$ bzr commit -m "break"
Committing to: /home/sechastain/workspace/test/
renamed del/sub => sub
missing sub/b
deleted del
deleted del/sub/a
deleted del/sub/b
Committed revision 3.

$ bzr status
$

[Matthew Fuller (fullermd)]

This looks similar to bug 187169. It's not exactly the same; 187169's trigger requires the partial commit, and fails the second time. May be the same underlying bug, though.

[John A Meinel (jameinel)]

If you tell bzr about the delete before hand it does fine (replace the rm sub/b with bzr rm sub/b).

It appears to be an interaction between the auto-unversion code and the apply delta code. It certainly does seem related to bug #187169.

The code path is slighty different, though. Specifically, we are getting a case where the code is claiming "this file is really deleted" but the record on disk claims that it was still present (which is why 'bzr rm sub/b' works, because it records it as genuinely removed.)

I'm guessing the WT.unversion() call isn't marking all references as absent, but I'll try to look into it a bit more.

[Robert Collins (lifeless)]

John, are you actually working on this?

[John A Meinel (jameinel)]

I am not actively working on this. I think I started to, and then was distracted by N other things.

[Robert Collins (lifeless)]

Little script to demo it. With improvements in dirstate robustness this now fails with a clearer error and also doesn't succeed on the repeated commit.

Committing to: /tmp/foo/test/
deleted del
renamed del/sub => sub
deleted del/sub
missing sub/b
renamed del/sub/b => sub/b
aborting commit write group: InconsistentDelta(An inconsistent delta was supplied involving '<deleted>', 'sub-20090715024931-bjc5um3nz7jsv3ef-2'
reason: The file id was deleted but its children were not deleted.)
bzr: ERROR: An inconsistent delta was supplied involving '<deleted>', 'sub-20090715024931-bjc5um3nz7jsv3ef-2'
reason: The file id was deleted but its children were not deleted.