8 comments

[ 3.2 ms ] story [ 14.9 ms ] thread
"it's radical because it's really easy to use."

Subversion is especially easy to use if you have to go through an HTTP proxy which doesn't forward WebDAV requests.

Another reason I love Subversion is that it remembers what revision I started a branch at. Could you imagine using a VCS which didn't do that? You'd have to write down the branch number somewhere and manually create a forward patch list anytime you wanted to merge.

Old versions of Subversion required you to remember the revision, but since 2009 and version 1.6, that is no longer the case.

A modern SVN workflow can easily look like this:

  svn co https://svn.example.com/myproject/trunk .
  svn copy . ^/branches/feature_branch -m 'Created feature branch'
  svn switch ^/branches/feature_branch
  svn ci -m 'Added foo baz'
  svn switch ^/trunk
  svn merge ^/branches/feature_branch .
  svn rm ^/branches/feature_branch -m 'Closed feature branch'
So because you've chosen a UI you like for Subversion, but haven't done so for Git (yet), git sucks, and by extension so does DVCS?

Even if you disliked all the Git UIs, there are some for Hg that are almost exact clones of their subversion counterparts.

Unconvincing.

SVN is not only a UI. If you get deeper into how scm's are implemented you should be able to appreciate the differences and tradeoffs between SVN and git. For one, git completely fails at bigger repos. It is just the reality.
In what way does it 'fail' at bigger repos? It was designed to handle the largest and most complex OS repo that exists.

For me the most amazing thing about git is how it is built out of very simple blocks. Each commit or object is a simple hash of it's contents. Which is just brilliant really. That's why it so fast and avoids any potential data corruption.

Incorrect. OS repos are miniscule compared to gaming and EDA companies with huge digital assets that need to be versioned as well (insert comments questioning why you would ever need digital asset revisioning with code, here).

The killer "feature" of SVN is partial checkouts. If im not mistaken, perforce and bitkeeper have this feature.

The core critical point that I have about subversion is that you'll likely ruin your perfectly working code by the having to "svn up" before you can "svn ci".

In git it's the other way round, you can go back to your working version and start over with fixing a conflict.

The article is from 2008. Things change.