Comment 6 for bug 393349

So it does, indeed, seem possible to trigger this via bundles. I'll repeat my comment from bug #390563 describing the problem.

1) A stacked branch is valid if:
   a) For the list of Revisions that are present, has the corresponding
      inventory for all of those revisions (at least a delta)
   b) for the delta of all those inventories, has the corresponding file texts
   c) for any base which an inventory is delta'd against, has the corresponding
      inventory.
      If we don't have a base, then we require the full inventory for the
      revision, and all referenced file texts.

2) With bundles, it violates (c). The insert-data-from bundle inserts all
   of (a) and (b), but it doesn't bring in the inventories from parent
   revisions, nor does it include the referenced texts.

3) Note also that *commit* does the wrong thing as well. For heavyweight
checkouts, I think it does fine, because it generates the data locally, and
then uses fetch to push it to the remote. But for lightweight checkouts, it
doesn't 'fill in' any parent inventories or referenced texts.

Here is a test case that reproduces it. Note that we may not need all 500
files, but we need something large enough to cause the CHK pages to split.

# create a 500 file tree
bzr init --2a source
cd source
for i in `seq 10`; do mkdir $i; for j in `seq 50; do touch $i/$j; done; done

bzr add -q
bzr commit -q -m "add 500 files"

echo foo > 5/5
bzr commit -m "5/5"

echo bar > 6/6
bzr commit -m "6/6"

cd ..
bzr branch source target
echo baz >target/7/7
bzr commit -m "7/7" target

(cd target; bzr send -o ../my.patch ../source)

bzr branch --stacked source stacked

cd stacked
bzr pull ../my.patch #boom