Refactoring to interfaces: if only Subversion could understand

There is a refactoring I do in Eclipse sometimes that confuses Subversion:

Suppose I have a class named MessageSender.  It does not implement an interface; it just does the work itself.  Now perhaps I want a MessageSender to be an interface and have a MessageSenderImpl.  To accomplish this change, I:

  1. Rename MessageSender to MessageSenderImpl.
  2. Extract Interface on MessageSenderImpl and call it MessageSender.

At this point, I can see that Subversion is confused, because there is a little red X in the icon for MessageSender.java in the Package Explorer:

If I commit my changes now, MessageSender.java will be deleted and the build will be broken if I have any code using the new interface.

My current workaround is to:

  • Revert MessageSender.java, then
  • Replace With Previous from Local History

But this is more work than it oughter be, ain’t so?

Update 10/13/2008: Karl’s comment inspired me to post my question to the Subclipse email list, where Mark Phippard told me that an enhancement to Subclipse released in Subclipse 1.4.3 fixes this issue.  (I was using Subclipse 1.4.2).  I upgraded Subclipse to the current version (1.4.5) and now my two-step refactoring works (i.e., after step 2 the file is marked as changed rather than marked for deletion, so I don’t have to do my workaround).

Thanks, Karl and Mark!