Comment 4 for bug 507566

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

John A Meinel wrote:
> I can confirm this behavior with bzr/2.0 tip and with bzr.dev tip.
>

I think I've tracked down the cause, I haven't tracked down an
appropriate fix.

Specifically it has something to do with us having written the pack file
down and gotten it 'into the mix' (that may just be in self._names).

The issue is that if we trigger "reload_pack_names()" as a side-effect
it sets "self._packs_at_load".

Let me try a walk through...

1) branch 1 starts a commit, creates a new pack file on disk renames it
into final position, writes the indices, etc. At this point
self._names[] includes that named file, but .bzr/repository/pack-names
does not.

2) branch 2 does the same
3) branch 1 takes out the disk lock to update the pack-names file, it
then reads the pack-names file to see if anyone has inserted something
since it last checked, and does a 3-way diff comparing:
  BASE = self._packs_at_load
  THIS = self._names
  OTHER = the newly read pack-names file

4) branch 1 then writes out a new pack-names file, (after autopacking,
and deleting some files, etc.)

5) At this point branch 2 goes to autopack, but finds that a file is
missing, so it calls self.reload_pack_names(). As a side effect, this
sets self._packs_at_load to the current 'disk_nodes' but this *includes*
new_nodes.

6) the new diff doesn't think the new nodes are still new, so it doesn't
try to write them to the index file.

...

I'm missing something. The state I see right now is that:

self._names => 7 items
but
self._diff_pack_names returns

disk_nodes => 6 items (missing 75b...)
new_nodes => empty
deleted_nodes => empty

I really don't understand how we can read from disk, and then add
everything in self._names, and come up with less than 7 items...

Anyway more investigation needed, but current signs point to an issue
with
bzrlib.repofmt.RepositoryPackCollection.{_diff_pack_names,_save_pack_names}

I'm also curious if we have a bug based on the new unlocking exception
supression. This is less likely, but maybe the commit isn't supposed to
succeed, but it is going through an unlock phase which suppresses that
exception, and tells the branch that it is ok to use the new revision_id....

John
=:->

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

iEYEARECAAYFAktRLjgACgkQJdeBCYSNAAOhrACdEnhm+RsAD+kDIgZNSQb/05U1
idgAn2QtU6PjUKiC5KwQLHS+iC25wYHV
=QvFI
-----END PGP SIGNATURE-----