On Sun, 2006-05-21 at 02:46 +0000, Michael Ellerman wrote:
> What you could do is use the hash to spot when a file is moved and not
> modified. But doing that would be pretty expensive, and might sometimes
> be confusing.
And wrong from time to time. A better approach is IMO the inode. If the
inode is the inode of a file known from the cache, and the datestamp
makes it a cache hit, then its a good candidate for 'this has been
moved'.
> So I don't think you want to do it automatically, but you could have a
> command that runs through and tries to spot renames after the fact.
I think having a command to detect renames for you is good. +1 on that.
I think having bzr notice and 'just record it' is terrible UI wise. -1
on that. (for the same reason that 'bzr add' is good, but bzr auto
adding would be bad; and bzr commit should complain on deleted files
rather than auto-deleting).
On Sun, 2006-05-21 at 02:46 +0000, Michael Ellerman wrote:
> What you could do is use the hash to spot when a file is moved and not
> modified. But doing that would be pretty expensive, and might sometimes
> be confusing.
And wrong from time to time. A better approach is IMO the inode. If the
inode is the inode of a file known from the cache, and the datestamp
makes it a cache hit, then its a good candidate for 'this has been
moved'.
> So I don't think you want to do it automatically, but you could have a
> command that runs through and tries to spot renames after the fact.
I think having a command to detect renames for you is good. +1 on that.
I think having bzr notice and 'just record it' is terrible UI wise. -1
on that. (for the same reason that 'bzr add' is good, but bzr auto
adding would be bad; and bzr commit should complain on deleted files
rather than auto-deleting).
Rob
-- www.robertcolli ns.net/ keys.txt>.
GPG key available at: <http://