Comment 10 for bug 5158

It doesn't help the problem Aaron is commenting on.

I can setup vim so that when I save the file, it renames the current file to a backup file, and saves a new file in its place.

(I used to use this, coupled with deleting the backup file, so that vim would break hardlinks when using hardlinked Arch working trees).

Anyway, if you don't delete the file, suddenly your filename has changed from 'foo.py' to 'foo.py~', and you have a new file named 'foo.py'.

Lots of applications use rename as a way to atomic updates to files (create a temp file, rename it over top the existing file).

I don't know many other ways that rename puts things out of the way, but backup files are an obvious use case.

So Aaron's basic comment is that the function call 'rename("a", "b")' at an os level does not mean you intend to move a to b. Running the command line 'mv' probably does, as does renaming the file in your IDE, etc. But not at the OS level.

I think bzr should support running 'bzr mv a b' after you already ran 'mv a b'. That is completely fixable (rather than having to do the opposite 'mv b a; bzr mv a b'). Auto detecting renames is not.