Why Subversion sucks

OK, the title may be a bit hard. Initially this was a short collection of stuff I (TobiX) find annoying about Subversion. Some people added stuff, so has become a generic list of things some people don't like about Subversion. Feel free to add to the list. If something written here is wrong, please leave a note. But I am forced to use Subversion in some cases...

• Merging is not history-sensitive - Subversion does not record what was merged. Or as the Subversion book says:

Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible.

Unfortunately, Subversion is not such a system. Like CVS, Subversion does not yet record any information about merge operations. When you commit local modifications, the repository has no idea whether those changes came from running svn merge, or from just hand-editing the files.

Subversion 1.5 adds merge tracking but you still have to help it along. Reintegration merge (merging a side branch back into trunk after regularly merging stuff from trunk into the side branch) requires that you use the special --reintegrate flag to svn merge. SVN should really figure this out by itself. Of course, you also still have to use repository URLs all the time. Example:

svn info # (yes, of course I forgot the exact URL of the repository)
svn copy url://.../trunk url://.../branches/foo
svn switch url://.../branches/foo
# hack hack hack
svn commit
svn merge url://.../trunk
svn commit
# hack hack hack
svn commit
svn merge url://.../trunk
svn commit
svn switch url://.../trunk
svn merge --reintegrate url://.../branches/foo
svn commit

• Diffing between branches is overly complicated. Example: Diff the current version of a file against the last release:

svn info
svn ls svn+ssh://.../tags
svn diff --old svn+ssh://.../tags/tag --new svn+ssh://.../trunk/ file with path

The svn info was for: "Duh, what was the repository URL again?"

Comment: You're making this a lot more difficult than it needs to be. There are diff tools that simplify this quite a bit.

Sorry, I didn't find any. Can you give me some pointers? I prefer CLI tools. TobiX 20:46, 18 Aug 2005 (CEST)

Compare that with CVS (not my version system of choice, but everyone knows it):

cvs log file | head -50
cvs diff -r tag -r HEAD file

• Why do I have to use the reposity URLs all over the place? I want something like tla register-archive for Subversion.

• The Subversion "revision numbers" are mostly meaningless. The CVS version numbers at least told me if I was working on HEAD or at a branch. The Arch version numbers are strict, but carry much meta-information, like the name of the branch or the state of the current working tree.

Comment: If these are your biggest complaints with Subversion then I would say that you should be promoting Subversion, not putting it down.

I think that history-sensitive merging is a feature a modern SCM really should have. That is my number one critic of Subversion. TobiX 20:46, 18 Aug 2005 (CEST)

• Subversion cannot force checkout. I want version control for my dotfiles. Tla and Darcs failed horribly, subversion works with some problems. What bugs me most: If a directory already exists (like .gnome) the checkout aborts, there is no way to force the checkout. I have to move the dir away, run svn and merge the two directories by hand. Desired behaviour would be to put the dir under svn control, overwrite all files which are found in the repo and leave the rest alone. Btw, it is impossible to checkout /home/user/.ssh like this if your access method is svn+ssh ;)

--87.78.0.174 14:57, 31 Aug 2005 (CEST)pzzzp

• Subversion does not support atomic checkout. You can get errors during a commit or update and wind up with a database or local machine in an inconsistent state.

• Subversion is miserably slow, probably on the order of 100x the amount of time required for a similar operation using Perforce.

Comment: What operation? svn copy is very fast, e.g. --192.138.150.250 19:29, 8 August 2006 (CEST)

Comment: svn merge is very slow. on windows it's hopeless (on the order of 2 files per second)

Comment: svn commit and svn update are pretty slow too, compared to certain other SCM systems; especially when SVN is used via WebDAV. --84.187.162.164 09:28, 27 July 2008 (UTC)

• During an update or a commit you may get common errors that completely halt operation, such as a failed add. There's no reason for this to halt the operation, it can be handled like normal conflicts.

• Labeling/Tagging in subversion is pretty clumsy and doesn't enforce the read only nature of a label, while a movable tag to indicate something like the stable level of a branch is overcomplicated by the associated "branch" that svn creates for you just to get the tag functionality.

• A lot of the problems with SVN's branch/tag/label/sandbox support stems from the fact that it doesn't know the diffrence between those four concepts. Instead it lumps them under its copy/merge functionality, and expects the user to enforce the diffrences. Much of what you would expect your version control system to do automatically (merge changes in the main trunk automatically into the sandbox, enforce read only nature of a label, etc) arn't handled without a lot of external scripts and hooks.

• No support for branching and merging branches.

Comment: Copies are branches, unless I misunderstand you... --192.138.150.250 19:29, 8 August 2006 (CEST)

What the original writer wanted to say is probably the same I said in the very first argument on top of this page. "Branches" are just copies, Subversion has no support for intelligent merge, so it's mostly useless for heavily branched development. TobiX 19:57, 13 August 2006 (CEST)

• Subversion has a centralized design. You realize how much this is painful when working on a remote repository and the server goes down: no way to commit. As a direct consecuence, a lot of other funny things are not possible: local branches, repository syncronization, anonymous dumps.

• There's no way to cancel the last commits, apart from dumping the repository, edit it by hand and create a new empty repository to be populated by the modified dump... simply ridiculous. Although the manual shows this as a feature, it is my opinion this operation is difficult to implement in subversion, so it became a feature.

• There is no convenient way to check if a svn update would cause conflicts, or to even properly undo the update. To add injury to insult, you *have* to update before committing if some of your changed files have been touched upstream since. In various DVCS systems you just commit your changes locally and then perform an operation similar to update (creating a merge which you could then push to upstream). When it conflicts you can just undo the update and return to your last local commit.