bzr: ERROR: The file id "foo-20080731224042-7ogu3b3hk0bwnpo3-1" is not present in the tree

Bug is present in 1.3.1-1, as well as 1.6~beta3-1

Hi,

Thanks for the bug.

I can see this
        cur_file_id = tree.path2id(relpath)
        rev_tree = b.repository.revision_tree(revision_id)
        old_file_id = rev_tree.path2id(relpath)

        if name_from_revision:
            if old_file_id is None:
                raise errors.BzrCommandError("%r is not present in revision %s"
                                                % (filename, revision_id))
            else:
                content = rev_tree.get_file_text(old_file_id)
        elif cur_file_id is not None:
            content = rev_tree.get_file_text(cur_file_id)
        elif old_file_id is not None:
            content = rev_tree.get_file_text(old_file_id)

so it assumes that a file id in a newer revision will be present in an older one.

I haven't thought it through, but it probably wants to either try old_file_id first,
or catch the error in the new_file_id use.

I think the former, othewise there may be no way to access certain paths in
the old revision.

This sort of thing occurs in a few places, maybe we need to look
at a way to specify whether you are talking about a current path,
an old one, or a specific path over time, regarless of file ids (for log).

Thanks,

James

Actually, in this particular case, I would guess that LaMont would rather just have the file restored with its old file-id.

I don't know his specific use case, but I think he was using "bzr add" as a substitute for 'bzr revert'.

I run into this same error when using bzr shelve/unshelve, causing shelved changes to remain shelved (see attachment).

Output from bzr --version:

Bazaar (bzr) 1.11
  Python interpreter: /System/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python 2.5.1
  Python standard library: /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
  bzrlib: /Library/Python/2.5/site-packages/bzrlib

That's a bug, we try to find the file content under the file id used in the current working tree and fail to fallback to the old file id if it can't be found in the requested revision.