4/5 are problems unrelated to SVN. Heck, Git can burn you on all of those.

1/5 is about using svnserve instead of file:// and network mounts, and doesn't need to be a rant, just a don't use file:// protocol for shared repositories.

I wish HN had downvotes for an article like this.

Thanks for the sophisticated and helpful response. I'll obviously implement many of the suggestions you made to improve my article writing.

> It's neither reliable nor safe, nor can you easily administrate it.

While you're at it, the word you wanted was 'administer'.

It's more of a "how to fail at version control", yes - but with a Subversion slant (along the lines of "it can work fine, but the default is bad").

I don't see how that makes this a particularly bad article, though.

I'm guessing that you've never had to use svn+ssh:// with a group of developers. The file permissions hell you get into using that with multiple users is very frustrating.

I much prefer the http:// access method, and have never had a locking problem.

> By default in SVN, everyone is committing to the same - and indeed the master, de-facto, controlling, always perfect - branch. Trunk.

It's worse than that; svn asks you to maintain the trunk/tags/branches directory structure yourself, rather than including them as core concepts in the VCS itself(1). So, someone can commit an update to something under tags/ and svn won't even give out a warning, since it has no idea that tags/* are supposed to be write-once.

1) Looks like they added `svn branch`, sometime after the 1.4.x version I'm actually using.

Pffft. Complaining about TortoiseSVN? Use SmartSVN - it works in all 3 OSes, too. I know, I've had to use it in all 3 and it's nice to have that consistancy.

Every time I read something about SVN I just thank god I don't have to use it anymore. Just the thought of a merge-heavy workflow in svn gives me the willies.