Renames can remove file!

[J.S. van Bethlehem]

Actually: if you think about what hg really does when you rename
something, your results make sense:

> [ybusenet at login03 zoo]$ hg rename foo foo.orig
> [ybusenet at login03 zoo]$ hg rename bar foo

A rename is not just a rename, but it really means a copy+delete. So
when you type the first command, a copy of foo is created, named
foo.orig and foo is marked for deletion. Then a copy of bar is created,
named foo and bar is marked for deletion. At this stage for example:
 $ hg st
A foo.orig
R bar
R foo

> [ybusenet at login03 zoo]$ hg commit -m "test"
> No username found, using 'ybusenet at login03.xxx.com' instead
> [ybusenet at login03 zoo]$ ls
> foo  foo.orig
I got the same. That's confusing, because foo was marked for deletion.
So apparently hg tries to be smart and detects somehow that foo should
remain, but does not correctly deal with this in the changeset. In that
view this would be a bug you should report.

An easy way out to prevent this type of problems, is to do a commit
after each separate rename. That will function as you expect.

Yours sincerely, Jakob