IndexError in multiparent _reconstruct reading bundle

[MikeH]

Newbie trying to set up bzr and figure out how it works...

Local pc has a branch on it in which I've created a simple text file, amended it and commited the change. I've then run send to generate a file I can copy to a server to apply the change to.

There is no direct link between local pc to the server so I've copied the send output file onto usb stick, from there onto another local machine which has network access and then onto the server, (development machines aren't allowed onto the internal network for security reasons).

The server has a branch with a text file identical to that on the original local pc, but there's no connection between the server and local branches, i.e. one wasn't generated from the other. I'm trying to update it with the patch generated from the local machine but it fails, the following output is produced:

bzr: ERROR: exceptions.IndexError: list index out of range

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 842, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1037, in run_bzr
  File "bzrlib\commands.pyo", line 654, in run_argv_aliases
  File "C:/Program Files/Bazaar/plugins\qbzr\lib\commands.py", line 787, in run
  File "bzrlib\commands.pyo", line 1037, in run_bzr
  File "bzrlib\commands.pyo", line 654, in run_argv_aliases
  File "bzrlib\builtins.pyo", line 3693, in run
  File "bzrlib\merge.pyo", line 177, in from_mergeable
  File "bzrlib\merge_directive.pyo", line 240, in install_revisions
  File "bzrlib\bundle\serializer\v4.pyo", line 471, in install_revisions
  File "bzrlib\bundle\serializer\v4.pyo", line 539, in install
  File "bzrlib\bundle\serializer\v4.pyo", line 569, in _install_in_write_group
  File "bzrlib\bundle\serializer\v4.pyo", line 690, in _install_inventory_records
  File "bzrlib\multiparent.pyo", line 167, in to_lines
  File "bzrlib\multiparent.pyo", line 502, in get_line_list
  File "bzrlib\multiparent.pyo", line 512, in cache_version
  File "bzrlib\multiparent.pyo", line 661, in reconstruct_version
  File "bzrlib\multiparent.pyo", line 654, in _reconstruct
IndexError: list index out of range

bzr 2.0.3 on python 2.5.4 (Windows-2003Server-5.2.3790-SP2)
arguments: ['C:\\Program Files\\Bazaar\\bzr.exe', 'qsubprocess', '--bencode', 'l5:merge13:test-send.txt11:--directory32:C:/Bazaar Working Directory/teste']
encoding: 'cp1252', fsenc: 'mbcs', lang: None
plugins:
  bzrtools C:\Program Files\Bazaar\plugins\bzrtools [2.0.1]
  explorer C:\Program Files\Bazaar\plugins\explorer [0.8.3]
  launchpad C:\Program Files\Bazaar\plugins\launchpad [2.0.3]
  netrc_credential_store C:\Program Files\Bazaar\plugins\netrc_credential_store [2.0.3]
  qbzr C:\Program Files\Bazaar\plugins\qbzr [0.14.5]
  rebase C:\Program Files\Bazaar\plugins\rebase [0.5.4]
  svn C:\Program Files\Bazaar\plugins\svn [1.0.0]
  upload C:\Program Files\Bazaar\plugins\upload [1.0.0dev]
  xmloutput C:\Program Files\Bazaar\plugins\xmloutput [0.8.5]

*** Bazaar has encountered an internal error. This probably indicates a
    bug in Bazaar. You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

I've attached the output file generated by send for reference. The target file for updates was called test.txt.

[MikeH (michael-hughesdon)]

Didn't mention in my original post, I'm running the Windows version of bzr.

The patch was generated in an attempt to generate details of the most recent commit on a branch, which I've since figured out you can't do with send, (do enough people ask for this to add it to send, or to create a new command, 'revision-patch' or somesuch?). The resulting output, I guess, lacks change details so the merge is perhaps failing to handle an empty file condition?

Hope that helps.

[Andrew Cowie (afcowie)]

bzr: ERROR: exceptions.IndexError: list index out of range

With bzr 2.1.1 on Linux (Ubuntu Lucid) trying to merge a bundle resulted in the crash dump, attached.

AfC

[Andrew Cowie (afcowie)]

Ok, a smaller bundle succeeded. The offending bundle brought a much larger set of revisions. I have preserved the branch at that state, and have the bundle as well. Both available on request (yes, it's open source code).

AfC