unable to get mtime for renamed file from PreviewTree

[Alexander Belchenko]

This bug affects QBzr actually, but it's still bug.

QBzr 0.9.2 provide additional option `--qpreview` for `merge` command. For preview used qdiff window with side-by-side view (by default). Side-by-side view needs to know timestamp of file from old and new tree. To obtain timestamp QBzr used construct like this (not exactly this):

date = tree.get_file_mtime(file_id, abspath)

This code fails with error when you want to preview merge in which some file only renamed but not modified. Here is traceback:

C:\Temp\1>python C:\work\Bazaar\mydev.packs\bzr.dev\bzr merge --qpreview ../2
Traceback (most recent call last):
  File "C:\work\Bazaar\plugins-repo\qbzr\lib\diff.py", line 159, in load_diff
    dates[ix] = self.trees[ix].get_file_mtime(file_id, paths[ix])
  File "C:\work\Bazaar\mydev.packs\bzr.dev\bzrlib\transform.py", line 1561, in get_file_mtime
    return self._transform._tree.get_file_mtime(file_id, path)
  File "C:\work\Bazaar\mydev.packs\bzr.dev\bzrlib\workingtree.py", line 576, in get_file_mtime
    return os.lstat(self.abspath(path)).st_mtime
WindowsError: [Error 2] : u'C:/Temp/1/foo'

Regular merge --preview is not affected by this bug, because it don't try to show timestamp at all:

C:\Temp\1>python C:\work\Bazaar\mydev.packs\bzr.dev\bzr merge --preview ../2
=== renamed file 'bar' => 'foo'

Here the body of get_file_mtime in transform.py:

    def get_file_mtime(self, file_id, path=None):
        """See Tree.get_file_mtime"""
        if not self._content_change(file_id):
            return self._transform._tree.get_file_mtime(file_id, path)
        return self._stat_limbo_file(file_id).st_mtime

Obviously content is not changed in the case of rename.

[Alexander Belchenko (bialix)]

qbzr has workaround for this bug.

[Aaron Bentley (abentley)]

It looks like the call to self._transform._tree.get_file_mtime should not provide path-- for renamed files, that will be wrong.

[Vincent Ladeuil (vila)]

Marking In Progress as a patch exists and has been reviewed.
Work seems to have stalled here tough :-/