Why Subversion sucks
Revision as of 15:16, 10 August 2005 by 67.71.20.69 (talk)
(Also known as 'A few of my personal annoyances that aren't actually a bid deal at all')
OK, the title may be a bit hard. Here is just a short collection of things I (TobiX) find annoying about Subversion. If you also don't like Subversion that much, feel free to add your own list. If something I say 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.
- 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?"
- 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.