bzr: ERROR: not well-formed (invalid token)

Confirmed, I have the same error here.

Are there perhaps any files in the repository that contain newlines in their name?

This looks like invalid XML in the repository. Are you using bzr-svn or some other foreign format. Also can you run 'bzr check' please.

I have a similar problem. I'm running Ubuntu 9.04. I had the problem with the version included in Jaunty, as well as the more up-to-date package from http://ppa.launchpad.net/bzr/ppa/ubuntu

I thought that I had a corrupt archive, since I pulled it in off a failing drive.

bzr status works, as does bzr log. However bzr check gives me:

bzr check
Checking working tree at 'file:///home/web/work/veridic/'.
bzr: ERROR: not well-formed (invalid token): line 12, column 58

Trying to commit my current changes
bzr commit -F commit_message.txt
Committing to: /home/web/work/veridic/
aborting commit write group: UnexpectedInventoryFormat(not well-formed (invalid token): line 12, column 58)
bzr: ERROR: not well-formed (invalid token): line 12, column 58

I'm not at all familiar with python, can anyone give me pointers where to look further?

This might indicate drive-level corruption.

Probably a good thing to do next would be to get the traceback from ~/.bzr.log and also the output of 'bzr info' in that directory.

Here's a ~/.bzr.log excerpt for commit:

Fri 2009-06-26 01:20:18 +0200
0.012 bzr arguments: [u'commit', u'-F', u'commit_message.txt']
0.021 looking for plugins in /home/users/john/.bazaar/plugins
0.021 looking for plugins in /usr/lib/python2.6/dist-packages/bzrlib/plugins
0.063 encoding stdout as sys.stdout encoding 'UTF-8'
0.085 opening working tree '/home/web/work/veridic'
0.108 preparing to commit
[22075] 2009-06-26 01:20:19.065 INFO: Committing to: /home/web/work/veridic/
0.125 Selecting files for commit with filter []
0.147 aborting commit write group because of exception:
0.148 Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 363, in commit
    self._update_builder_with_changes()
  File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 644, in _update_builder_with_changes
    self.work_tree, self.basis_revid, iter_changes):
  File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 585, in record_iter_changes
    revtrees = list(self.repository.revision_trees(self.parents))
  File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 2323, in revision_trees
    for inv in inventories:
  File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 2184, in _iter_inventories
    yield self.deserialise_inventory(revision_id, text)
  File "/usr/lib/python2.6/dist-packages/bzrlib/repository.py", line 2206, in deserialise_inventory
    entry_cache=self._inventory_entry_cache)
  File "/usr/lib/python2.6/dist-packages/bzrlib/xml_serializer.py", line 75, in read_inventory_from_string
    raise errors.UnexpectedInventoryFormat(e)
UnexpectedInventoryFormat: not well-formed (invalid token): line 12, column 58
[22075] 2009-06-26 01:20:19.091 INFO: aborting commit write group: UnexpectedInventoryFormat(not well-formed (invalid token): line 12, column 58)
0.164 Traceback (most recent call last):
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 729, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 924, in run_bzr
    ret = run(*run_argv)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commands.py", line 560, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/usr/lib/python2.6/dist-packages/bzrlib/builtins.py", line 2937, in run
    exclude=safe_relpath_files(tree, exclude))
  File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 192, in write_locked
    result = unbound(self, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/workingtree_4.py", line 226, in commit
    result = WorkingTree3.commit(self, message, revprops, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/decorators.py", line 192, in write_locked
    result = unbound(self, *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/mutabletree.py", line 228, in commit
    *args, **kwargs)
  File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 363, in commit
    self._update_builder_with_changes()
  File "/usr/lib/python2.6/dist-packages/bzrlib/commit.py", line 644, in _update_builder_with_changes
    self.work_tree, self.ba...

It looks like a good next step would be to look at the extracted
inventory and see whether the problem looks like on-disk corruption or
something that might have originated in bzr....

Robert is working on a tool that can pull data back from
partly-readable repositories.

--
Martin <http://launchpad.net/~mbp/>

To get the inventory you should be able to do this:

in your shell, export BZR_PDB=1
run the command that fails
when it errors, you should get a debugger prompt
in it, type "pp xml_string"
and "pp locals()"

and paste the output into this bug, either directly if it's short or
as an attachment if it's long

if the filenames in your tree are confidential, you can change the bug
to be private first.

--
Martin <http://launchpad.net/~mbp/>

FWIW (which might not be much, this close to blessing 2a as the default format)...

Attached is a simple reproduction of what I think is the same problem, using bzr.dev r4596 (which is approximately 1.18rc1, not sure exactly). I'll summarize here. (The attachment contains the requested xml_string and locals() output from the debugger, along with a stack trace.)

To reproduce, create a branch (either standalone or shared-repo is fine), add file called "a^Gb" (literal CTRL-G character), and commit.

pack-0.92 and 1.14 demonstrate the problem; 2a does *not*; I haven't tried other formats.

Once you've got a branch in this state, "check" fails. "log" succeeds, but "log -v" fails.

Importantly, "upgrade --2a" also fails. Thus, the fact that 2a itself doesn't suffer from the problem is little consolation to people with older branches that do suffer from it.

Here's a clue to a possible fix: "co" fails, but if you remove the file from your working tree (assuming, of course, that you haven't already "remove-tree"ed the latter), "revert" *succeeds* in restoring it. So there appears to be at least one code path that avoids the bug.

Bugs 267670, 346471, and 407303 look superficially like duplicates of this, but I'm not confident enough of that to mark them as such.