“A common desire is to refactor source code, especially in Java-based software projects. Files and directories are shuffled around and renamed, often causing great disruption to everyone working on the project. Sounds like a perfect case to use a branch, doesn’t it? Just create a branch, shuffle things around, and then merge the branch back to the trunk, right?

Alas, this scenario doesn’t work so well right now and is considered one of Subversion’s current weak spots.”

Subversion book

The fact that subversion lacks a true rename operation (it is done via copy & delete) you can get into a lot of troubles if you rename or move files in subversion if somebody else modifies the same file meanwhile. And by troubles I mean losing data! (If you want more info about it, check this bug entry. You will find the detailed use cases in the attached files there.)

For a fast rename (or move, which is exactly the same operation) & commit, there is a low probability you run into this issue (assuming the other guy also updates frequently), so things aren’t so critical here. But, when working with branches, it’s a whole new story. They will live much longer (from days to weeks or months) so the probability of somebody modifying a file renamed in another branch increases a lot. That effectively means you cannot rename or move files if you use branches. Yeah, you read it right. If you use branches, moving files is not safe. End of story.

So, what svn is forcing us to do is either:
a) Don’t rename files.
b) Don’t use branches.
c) Don’t use subversion.

a) is simply stupid, so let’s forget it. b) might be ok for some people/enviroments. c) is what you really should be doing if b) is not an option (which makes perfect sense).

If you are looking for alternatives, use git or mercurial.