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.
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.