Comment 7 for bug 632704

Thanks for the concern but we have recreated these repositories from scratch: there's no lost production data. There's also only the one revision difference between the corrupted client working tree (rev 2) and the repository (rev 3).

The debug is from the (corrupted) working tree and the repository that I saved for debugging only.

I'm more concerned about avoiding this situation again in the future (for myself and other bzr users)

Is it even possible to force a commit from a working tree that was originally rev 2 and then had some changes made, to a shared repository that is already happily updated at rev 3, without doing a bzr update of the rev 2 working tree first?

BTW we've moved on to bzr 2.2.0 in the meantime (the repository formats have not been updated). The error persists.

Here's the debug:

C:\gnms\bin-safe>bzr missing -v bzr+ssh://<email address hidden>:xxxx///home/bzr/gnms-xxxx-bin-safe/trunk/
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
Branches are up to date.

C:\gnms\bin-safe>bzr update
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
bzr: ERROR: Tree transform is malformed [('unversioned parent', 'new-144'), ('versioning no contents', 'new-165')]

C:\gnms\bin-safe>bzr commit -m "trycommit"
Connected (version 2.0, client OpenSSH_4.7p1)
Authentication (publickey) successful!
Secsh channel 1 opened.
bzr: ERROR: Working tree is out of date, please run 'bzr update'.

C:\gnms\bin-safe>