Blog - /Tech

I've had to explain this enough times that it merits its own page. SVK does not factor into these points because I consider it to not be part of subversion.

• Metadata is stored in every subdirectory, rather than in one top-level directory. This makes subversion unsuitable for backing up /etc, because it causes conflicts with various programs that have expectations about the contents of their directories.
• I can't make an offline copy to work on, unless I use some other revision control system to layer on top of it like Mercurial or bzr. If I'm using Mercurial and bzr to do this, I might as well have used them for the main repository as well.
• Subversion does not keep track of merges.
• Subversion does not handle renames in a sane way.
• It is easy to accidentally get the wrong directory from a project you're just starting on, thanks to Subversion's "every directory is a repository" model.
• If the people who host your repository go away, you lose the entire revision history. Not so with decentralized version control systems.
• Its name does not make sense. A centralized revision control system can hardly be labeled "subversive"! Decentralized version control systems fit that description much better.
• Subversion once failed to completely update a checkout, and a co-worker had to spin some magic to get it "completely" updated. This is not sane. CVS suffers from the same kind of problem.
• It's not what the cool kids are using.

More points will be added as I think of them.

So what's a better alternative? I would have to recommend Mercurial at the moment, though I am currently using GNU Arch for most of my projects.