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. The problem is that Subversion’s svn update command isn’t as robust as it should be, particularly when dealing with copy and move operations.
When you use svn copy to duplicate a file, the repository remembers where the new file came from, but it fails to transmit that information to the client that is running svn update or svn merge. Instead of telling the client, “Copy that file you already have to this new location,” it sends down an entirely new file. This can lead to problems, especially because the same thing happens with renamed files. A lesser-known fact about Subversion is that it lacks “true renames”—the svn move command is nothing more than an aggregation of svn copy and svn delete.
For example, suppose that while working on your private branch, you rename integer.c to whole.c. Effectively you’ve created a new file in your branch that is a copy of the original file, and you’ve deleted the original file. Meanwhile, back on trunk, Sally has committed some improvements to integer.c. Now you decide ...