Here is what I get on Windows:
Updating FilePath('c:\\users\\jameinel\\appdata\\local\\temp\\tmpvcldzh\\tkrzbu')
['C:\\Python26\\python.exe', '/Users/jameinel/dev/bzr/bzr.dev/bzr', 'pull', '-d', 'c:\\users\\jamein
el\\appdata\\local\\temp\\tmpvcldzh\\2hnyc5'] => Using saved parent location: C:/users/jameinel/appd
ata/local/temp/tmpk_ca5g/
bzr: ERROR (ignored): 'file:///C:/users/jameinel/appdata/local/temp/tmpvcldzh/.bzr/repository/upload
/ixn21ph3jwgmlld785iy.pack'
bzr: ERROR: File exists: u'C:/users/jameinel/appdata/local/temp/tmpvcldzh/.bzr/repository/upload/ixn21ph3jwgmlld785iy.pack': [Error 183] Cannot create a file when that file already exists
It would appear that we are getting a name collision. So one update script is creating a pack with exactly the same name as the other. One of them is thinking that this pack should be obsolete, and the other is thinking the pack file should be added.
Because of the exact content match, you end up with confusion on the 2-way diff of pack-names.
1) Process 1 creates abcd.pack
2) Process 2 fills upload/ with content that would create abcd.pack
3) Process 1 starts repacking, seeing that abcd.pack is now obsolete (the content will be combined into a different pack)
4) Process 1 updates pack-names indicating that it will now remove abcd.pack, at this point, it is considered safe to move abcd.pack to obsolete_packs because it is no longer referenced.
5) Process 2 reads pack-names and sees that abcd.pack does not exist, so adds it and releases the write lock
6) Process 2 renames the new pack from upload to packs/abcd.pack
7) Process 1 renames abcd.pack to obsolete_packs
If this is true, something is able to generate pack files that are colliding. This shouldn't really be possible, since if we have the content, we shouldn't think we need to pull it in again.
I guess if you are doing concurrent pulling from the same branch to the same repository, since the first update hasn't finished yet, it doesn't see the content is already present. And the second fetch starts before the first one finishes, doing exactly the same work.
I don't have an immediate solution, but I do think this could be a handle on the problem.
Here is what I get on Windows: 'c:\\users\ \jameinel\ \appdata\ \local\ \temp\\ tmpvcldzh\ \tkrzbu' ) \python. exe', '/Users/ jameinel/ dev/bzr/ bzr.dev/ bzr', 'pull', '-d', 'c:\\users\\jamein \local\ \temp\\ tmpvcldzh\ \2hnyc5' ] => Using saved parent location: C:/users/ jameinel/ appd temp/tmpk_ ca5g/ //C:/users/ jameinel/ appdata/ local/temp/ tmpvcldzh/ .bzr/repository /upload d785iy. pack' jameinel/ appdata/ local/temp/ tmpvcldzh/ .bzr/repository /upload/ ixn21ph3jwgmlld 785iy.pack' : [Error 183] Cannot create a file when that file already exists
Updating FilePath(
['C:\\Python26\
el\\appdata\
ata/local/
bzr: ERROR (ignored): 'file:/
/ixn21ph3jwgmll
bzr: ERROR: File exists: u'C:/users/
It would appear that we are getting a name collision. So one update script is creating a pack with exactly the same name as the other. One of them is thinking that this pack should be obsolete, and the other is thinking the pack file should be added.
Because of the exact content match, you end up with confusion on the 2-way diff of pack-names.
1) Process 1 creates abcd.pack
2) Process 2 fills upload/ with content that would create abcd.pack
3) Process 1 starts repacking, seeing that abcd.pack is now obsolete (the content will be combined into a different pack)
4) Process 1 updates pack-names indicating that it will now remove abcd.pack, at this point, it is considered safe to move abcd.pack to obsolete_packs because it is no longer referenced.
5) Process 2 reads pack-names and sees that abcd.pack does not exist, so adds it and releases the write lock
6) Process 2 renames the new pack from upload to packs/abcd.pack
7) Process 1 renames abcd.pack to obsolete_packs
If this is true, something is able to generate pack files that are colliding. This shouldn't really be possible, since if we have the content, we shouldn't think we need to pull it in again.
I guess if you are doing concurrent pulling from the same branch to the same repository, since the first update hasn't finished yet, it doesn't see the content is already present. And the second fetch starts before the first one finishes, doing exactly the same work.
I don't have an immediate solution, but I do think this could be a handle on the problem.