You need to log in before you can comment on or make changes to this bug.
1.) delete a file 2.) create a new file with the same name - it's status is removed guessing that there will be similar behavior when: 1.) renaming a file 2.) undo refactoring mercurial should check a files status in its interceptors create events and rollback/revert it if status = removed see other vcs modules for more info
I have reproduced the behavior that Tomas has described. I need to look at the other vcs modules to see what we should do about it.
This is actually by design, its the way Mercurial behaves: What is in the Status Window is a view of the Repository, so when you delete a file that was in the repo, Mercurial correctly schedules it for removal, removes it form the working dir and updates its status to Locally Removed. If you then create a new file with that name, it will be locally New but the commit has not yet happened so the status is not updated. On Commit the repository removes the file and the new file is then reported as Locally New and reflected in the Status View. It is strange but its by design in Mercurial so we'd be reluctant to hack around it in the interceptor code. Padraig has investigated this already and it has a number of risks due to the way the interceptor code is designed.
changing status
i see:) 1.) is there a chance to reflect somehow this "bizarre" state in the files annotation? it's quite confusing... 2.) or maybe invoking an explicit 'hg add' on the file? the status changes to modified and only one commit is needed however, the whole scenario doesn't seem to be a typical/frequent usecase. speaking for myself - feel free to close if you think this is how the plugin should work.
I have release noted this.
