Why Subversion does not suck (blog.assembla.com)

It sucked because we didn't have the possibility of distributed version control, even if we really wanted it.

Some people and some projects prefer centralized. That's fine. But you can't build a distributed version control system out of a centralized one.

I'm very happy that Subversion works for you. For me, it just blew up on an update, which corrupted the fragile .svn directories it litters all over the working copy. "svn cleanup" couldn't repair the damage. This sort of thing happens on a regular basis.

Git, on the other hand? No problems.

The issue with SVN is simply the work flow it forces you into. I can't tell you how many times I've looked at someone's repo and see .bak files everywhere. I know right away why they're doing this because I did it myself when I used CVS/SVN.

DVCS's let you branch off, experiment, and if it works out you can push everything into the main tree with the history included.

they're generally less forgiving of ugly, needlessly hacked-together systems...

Huh? Am I the only one who finds Subversion to be very confusing, at the conceptual level, compared to git? All that file-by-file history tracking, just waiting to trip you up when you try to move a file around? The fact that branching in SVN is hopelessly entangled with the concept of copying directories around in some remote repository? Here's the canonical example from the SVN book:

  svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Creating a private branch of /calc/trunk."

I guess I must be the only one who prefers:

  git clone git://github.com/mechfish/calc
  cd calc
  git branch my-calc-branch
  git checkout my-calc-branch
  # ... fiddle around, then when it's time to go back to master ...
  git checkout master   # note: no need to cd anywhere

I suppose that one downside of this is that all your coworkers don't get to automatically see the my-calc-branch on their centralized server. (How terrible it is that your every whim isn't being automatically published to the world!) Instead, when you want to push changes, you have to say something like this:

  git push origin my-calc-branch:refs/heads/my-calc-branch

Or you have to set this up a bit in advance:

  git config branch.my-calc-branch.remote origin
  git config branch.my-calc-branch.merge refs/heads/my-calc-branch

After which you can just do

  git checkout my-calc-branch
  git push

Whenever you want to push up the changes to my-calc-branch. This sort of incantation is not great, but that doesn't mean it can't or won't be improved, and it's not that big a price to pay.

The biggest problem with SVN is that getting started with it is so hard. As a git user, if I have a directory and I want it under version control, I do this:

  cd my-directory
  git init
  git add *
  git commit -m "Initial commit"

Done. Put this in a droplet script and your great-grandpa could do it. (He'd have to read some blogs to figure out what to do next, but at least it's a start. And even if all he knew how to do was this:

  cd my-directory
  git commit -a -m "I committed today"

and he did it every now and then, that would be great! Like a tiny, hidden, aperiodic, directory-specific version of Apple's Time Machine. His industrious great-granddaughter could use these snapshots to clean up after his PHP experiments...)

As an SVN user, you need to find a hosted repository, get admin permission on it, set up the canonical directory structure -- being very careful to heed these words from the SVN book (you did read the SVN book, right?):

While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies.

... and then import your project, being sure to get it imported into /trunk and not into /trunk's parent. Then you have to check it out -- being sure to check out /trunk, or at least to do all your work in /trunk, lest you screw yourself up or confuse yourself.

So I assume that by "ugly, needlessly hacked-together systems" you mean "systems that make you use the command line". The only reason Subversion seems at all simple to non-geeks (to the extent that it does, which isn't much of an extent) is that the authors of tools like TortoiseSVN and Versions have sweated bucketloads of blood to design beautiful interfaces which hide all this cruft from the end users. DVCS will get there. Give it time.

The article isn't really about SVN vs all DCVSs, though, it's specifally about subversion's interface vs. git's.

There's no reason a DCVS can't have a clean, easily usable interface (darcs's is better than git's, for example), but the git developers have focused on features and raw power over usability.

I understand your point about maturing technology, but distributed anything is usually hard for people to wrap their heads around the first time.

In this case, however, when they say "even X can use it", they definitely mean "X is stupid". From earlier in the article:

But, this growth industry of training doesn't reach designers, clients, and other non-programmers, because this stuff is just too complicated for them.

I'm not sure this generalization applies to even a significant portion of either designers or programmers. As a human who uses tools, I want my tools to be reliable first and foremost, but since 100% reliable is a fantasy, it is always wise to be both on the look out for more reliable tools _and_ to know the tools you to use constantly intimately, inside and out, so you are more productive and less surprised by gotchas that the tools have. A tool that fails unpredictably or in a way that can't be fixed is a useless tool. You must know the limitations of your tools, to not know the limitations is to be unable to recognize when something better comes along. Not exploring new options and not being well versed with your current tools, or just doing one or the other, is wearing blinders.

I have a lot to say about version control, but I won't get into the details here.

However, on the 'switch from CVS to SVN', I'll comment and say that SVN is far superior to CVS.

The whole 'changes committed to the repo up the entire repo version' alone make this worthwhile.

SVN is also less arcane in its usage.

SVN has better tools for, well, everything.

SVN integrates well with all major IDEs (mine being VIM, but also Monodevelop and Eclipse).

The switch from CVS to SVN also made our releases much easier to manage (merging branches is fairly trivial and tagging is a no-brainer).

If you're using CVS in a company, do yourself a favour and switch to SVN. The basic concepts are the same, so re-educating developers takes all of 5 minutes.