help on failing commits

[David Ingamells]

I've seen similar things, e.g. on a branch command (file://...):

bzr: ERROR: No such file: 
u'/home/CmsRoot/repos/CVTOOL/.bzr/repository/packs/8fa9827c9d45ad9c669af9896d065b20.pack': 
[Errno 2] No such file or directory: 
u'/home/CmsRoot/repos/CVTOOL/.bzr/repository/packs/8fa9827c9d45ad9c669af9896d065b20.pack'

or

bzr: ERROR: No such file: 
u'/home/CmsRoot/repos/CVTOOL/.bzr/repository/indices/e61b1272edcb74b8994bd8d1a849b355.tix': 
[Errno 2] No such file or directory: 
u'/home/CmsRoot/repos/CVTOOL/.bzr/repository/indices/e61b1272edcb74b8994bd8d1a849b355.tix'

A re-run has always worked so far. My suspicion is that while the failed 
command was not itself going over a network it is still network 
performance related, as it is likely that other users were concurrently 
doing bzr commands using the same repository via bzr+ssh://, and it most 
often occurs at times of heavy network load. if my suspicion is true it 
will be a difficult one to reliably reproduce :-(

Possibly somewhere in bzr there is a timeout that is too short, and the 
caller thinks that a timeout means that the file is not present.

We get it less often now (but still once yesterday and once last week 
that I know of) as I have been doing lots of things to reduce the 
network load, and bzr1.6.1 is much more efficient in its network usage 
than earlier versions.


Martin Pool wrote:
> On Tue, Oct 28, 2008 at 9:45 AM, Andrew King <eurokang at gmail.com> wrote:
>   
>> Just to confirm, I have seen this bug a number of times with different users
>> recently. We fixed the problem by calling bzr pack on the repository. I have
>> no idea why this works or what the problem is. We have seen it on both
>> windows and linux, running bzr-1.7.1. I did not file a bug.
>>     
>
> Tim was asking about 270405, which is where we get a 'file not found'
> error even though the pack file does exist.  If you're seeing that too
> on Linux that would be highly useful information.
>
> However, I suspect what you're actually getting is
> <https://bugs.launchpad.net/bzr/+bug/153786>, for which John just
> posted a fix.  In this case the pack file has been removed by a
> concurrent process and we need to catch up.
>
> So basically you can tell the difference by, after the error occurs,
> looking to see whether the named file is still present or not.
>
>