Pack moved to obsolete_packs, but still referenced in pack-names

Does .bzr/repository/packs/49ef04533e5410f03a9e1f78b25083b0.pack still exist, and if so would you mind attaching it to this bug? jam was curious to know its contents.

This happened again to the same shared repository. Different pack this time, but otherwise the same symptoms.

Here's a snippet from the .bzr.log from around the time this re-occurred:

0.124 opening working tree '/var/lib/buildbot/twisted/ubuntu-py2.6-wx/Twisted'
13.540 Packing repository GCRepositoryPackCollection(CHKInventoryRepository('file:///var/lib/buildbot/twisted/.bzr/repository/')), which has 14 pack files, containing 15858 revisions with hint ['12b63ed2bf595ccb466b1d7cb1a5bcc0'].
13.540 repacking 3 revisions
[ 2143] 2011-01-16 18:30:56.685 INFO: +N twisted/mail/topfiles/4740.feature
[ 2143] 2011-01-16 18:30:56.686 INFO: M twisted/mail/tap.py
[ 2143] 2011-01-16 18:30:56.686 INFO: M twisted/mail/test/test_options.py
[ 2143] 2011-01-16 18:30:56.826 INFO: All changes applied successfully.
[ 2143] 2011-01-16 18:30:56.967 INFO: Updated to revision 15716 of branch svn://svn.twistedmatrix.com/svn/Twisted/trunk
86.408 return code 0

Sun 2011-01-16 18:30:57 -0500
0.035 bazaar version: 2.2.2
0.035 bzr arguments: [u'version-info']
0.040 looking for plugins in /var/lib/buildbot/.bazaar/plugins
0.040 looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
0.080 encoding stdout as osutils.get_user_encoding() 'UTF-8'
0.122 opening working tree '/var/lib/buildbot/twisted/lucid32-pypy/build'
0.123 encoding stdout as osutils.get_user_encoding() 'UTF-8'
1.185 bzr-svn: using Subversion 1.6.6 ()
16.194 Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 912, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 1112, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 690, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 705, in run
    return self._operation.run_simple(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 135, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/cleanup.py", line 165, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 1342, in run
    accelerator_tree, hardlink)
  File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/branch.py", line 376, in create_checkout
    hardlink=hardlink)
  File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/branch.py", line 321, in _create_heavyweight_checkout
    checkout_branch.pull(self, stop_revision=revision_id)
  File "/usr/lib/python2.6/dist-packages/bzrlib/branch.py", line 1068, in pull
    possible_transports=possible_transports, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/branch.py", line 817, in pull
    stop_revision, overwrite, limit=limit)
  File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/branch.py", line 749, in _update_revisions
    project=self.source.project, mapping=self.source.mapping)
  File "/usr/lib/python2.6/dist-packages/bzrlib/plugins/svn/fetch.py", line 1528, in fetch
    self.target.pack(hint=pack_hint)
  File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 194, in write...

As far as I can tell this is an issue with the packs code.

bzrlib/knit.py, line 3371 in bzr-2.2.2 is inside a try/except that normally would handles this: catches NoSuchFile and re-raises it as a RetryWithNewPacks — unless self._reload_func is None. So presumably that's the case here. I wonder why...

The “why” is fairly clear I suppose: because RepositoryPackCollection.pack doesn't pass a reload_func to _execute_pack_operations (or have any other of the associated logic for retrying a failed pack). At a glance self.reload_pack_names looks like a sane thing to pass there. I'll dig deeper and see how I go...

Fix landed in lp:bzr/2.2, will be part of bzr 2.2.3.

Accepted bzr into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

SRU Verification:

I can't think of an easy way to reproduce the problem situation. If there is one, please post a script or instructions. Otherwise, I suggest we let the MRE go through without manual testing.

I can do this manually and it works. Based on the test case that Andrew proposed. The basic script is:

1) Create a repository with a few commits in it.
 bzr init foo
 cd foo
 echo bar > bar
 bzr add; bzr commit -m "bar"
 bzr commit --unchanged -m "two"
 bzr commit --unchanged -m "three"

2) At this point, I have to invoke bzrlib in order to get the right coherency. Basically, repo1 must want to repack, but have already cached its list of what pack files are available. And at the same moment, repo2 repacks.

 python -c "from bzrlib import branch; b = branch.Branch.open('.')
b.lock_write()
b.revision_history() # force the repository to read what pack files are available
repo2 = b.bzrdir.open_repository() # re-open with another repository
repo2.pack()
b.repository.pack()
b.unlock()
"

With bzr-2.2.2 this fails with a traceback. With bzr-2.2.3 this succeeds.

Note that I tested this only with the bzr branches, and not with the official packages installed. I'm currently running bzr-2.3.1 on Maverick, and I don't really know how to revert to the appropriate revisions. But at least this is a script for reproducing the failure.

This bug was fixed in the package bzr - 2.2.4-0ubuntu1

---------------
bzr (2.2.4-0ubuntu1) maverick-proposed; urgency=low

  [ Jelmer Vernooij ]
  * Update watch file to use 2.2 series.
  * New upstream release.
   + Fixes closing of leaked sockets to SSH subprocesses, which causes
     dput sftp uploads to hang. LP: #659590
   + Fixes the use of 'lp:' urls behind a http proxy. LP: #558343
   + Correctly sets the Content-Type header when http POSTing to comply
     with stricter web frameworks. LP: #665100
   + Fixes propagating tags to the master branch in a bound branch or
     heavyweight checkout. LP: #603395
   + Fixes the use of 'bzr resolve --take-other' if the file is
     involved in an unresolved text conflict. LP: #646961
   + Fixes https access with newer versions of python2.7. LP: #693880
   + Fixes crash during pack caused by a concurrent repository pack
     operation. LP: #701940
   + Fixes communication with the Launchpad web service when using
     launchpadlib >= 1.5.5. LP: #707075
   + Switches away from deprecated 'edge.launchpad.net' LP: #583667
   + Fixes resolving of content (and path) conflicts for files in subdirs.
     LP: #660935
   + Fixes nasty recursion loop while displaying branch opening error.
     LP: #687653

  [ Martin Pool ]
  * Propose for maverick SRU.
 -- Martin Pool <email address hidden> Thu, 07 Apr 2011 15:30:17 +1000