- Support for atomic transactions.
- Support for tracking move/renamed files and folders.
Here is the problem. The support for move/rename in Subversion is often not what user's expect it to be.
The support for move/rename in Subversion is really about maintaining history. If I rename a file, commit it and then examine its history, I can see the history of the file all the way back to when it was created, across any move boundaries. Likewise, if I want to get a copy of what a file looked like last year, I can do so without needing to know what the file was named last year. If these are the sort of features you are after, then Subversion provides them very well.
So what are the features that Subversion does not provide? For starters, you might want to take a look at issue #898 in the Subversion issue tracker.
Subversion implements a move/rename as a copy followed by a delete. The fact that the new file is a copy is the reason you get support for the previous history. The negative side effect of this can be seen in this simple scenario:
- Suppose you have a versioned folder named
foowith a file named
- Users A and B checkout
footo make some changes.
- User A renames
bazand commits the change.
- User B makes some changes to the code in
barand attempts to commit. The commit fails because
baris out of date. So far this is all normal and expected. User B then runs svn update. What happens?
- svn update will add new file
bazto the working copy of user B, and
barwill remain in the working copy as an unversioned file (if it did not contain modifications it would have been deleted). I think that most people would expect that the local copy of
barwould be renamed to
bazand now contain user B's changes merged with whatever changes were in the repository as a normal update would do.
- User B has to recognize this is what happened and transfer the changes to
bazbefore committing. Of course, they might also run svn add on file
barto put it back and then commit it. Perhaps because they did not really recognize or understand what happened.
This problem also manifests in other commands like merge. Imagine you have a branch with some customizations you are working on. A refactoring happens on trunk which involves the renaming of several files and folders. You now have lost the ability to use merge to bring the changes in the branch back to trunk, or vice versa. Or, more accurately, you have lost a lot of the automation that Subversion can normally perform for you during this operation.
If you read the referenced issue from the Subversion issue tracker you will see that solving this problem is a big challenge. I would not take the lack of this feature as a reason to not use Subversion, obviously I'd recommend that you DO use Subversion. However, it is important to understand how the tool works and what it does and does not do before making the switch. My big fear would just be for a project to switch so that they could do a bunch of refactoring work and then run into this limitation in Subversion and become angry. I think the advantage Subversion gives you is that you often can do those refactorings and take advantage of the history support that Subversion provides. However, if you are going to do this, you need to use communication with the rest of the team and try to coordinate it in a way that it does not impact the entire team.