A very useful link there. Quite pragmatic. It tells us that Subversion's experts believe its future lies in:

- "Huge projects where putting all the current source code on everyone's machine is infeasible."

- systems with very complicated permission schemes where "you just plain aren't allowed to give everyone all the data"

- "organizations whose users need to interact with repositories in complex ways... These things are probably most useful to the corporate world, and to governmental and military organizations." [Karl Fogel]

So, if you recognize yourself in any of those groups, learn SVN. But otherwise I'd start with git. You can pick up the necessary rudiments of SVN (or, god help me, CVS) later when you need them.

I believe Git is strictly better than SVN even for one-person-never-share style of development simply because of much, much, much better branching/merging.

Being able to maintain and merge multiple branches without any effort is a huge, in my opinion. I don't think you can get away without using at lest some branching features in any project: at the minimum you'd need to maintain tags for released versions and keep "latest stable" from "development/experimental" code separated. And this is where Git shines.

I'm not saying SVN can't do branches or tags, I'm saying it takes more effort, and tools in general are supposed to make hard things easy.

By strictly, I think most developers mean one SCM tool's functionality is a strict superset of another's. That is not the case with git and svn! Git is probably qualitatively better for most competent developers, but for strictly, every feature counts -- git's support for handling binary files, in terms of size and content, is not as complete as svn's; and tree tracking is just completely different.

This means some developers will want things that svn can do but git can't. I don't think it's fair to deny that these gaps exist when some projects depend on it.

I'd say git is better for that situation because it's so simple to set up. That's one thing it really does well. Tons of branches and other stuff are likely to be less of an issue on small, personal, non-shared projects.

I don't see why you shouldn't leverage branching in any small, personal, non-shared project. I got in the habit of making a branch any time I want to try anything out, after all most of my small projects are experimental in nature, and branching is perfect for experimenting with changes and ideas that you might otherwise be afraid to try using a single, linear history.

I don't get the argument that git is better for branched projects. I worked this way in subversion for years -- svn copy and svn merge work just fine. You can branch! You can merge! Huzzah!

Granted, git is a bit faster for branching (it can take svn a few seconds to set up a branch, especially if you're doing it remotely), but that slight time savings is more than offset by the time you spend reading man pages, only to learn that the various git commands really don't mean what you think that they mean (and don't get me started on the quirks and inconsistencies and bugs in git...)

I am not a fanboy -- just a guy who doesn't want to think about his version control, any more than he wants to think about his toothbrush.

It's not just that Git is faster at branching. The concept of a branch in Git is conceptually different to a branch in Subversion. In Subversion, a branch is analogous to a directory, and creating a branch is essentially a cheap and efficient directory copy. In Git, a branch is more akin to a reference or pointer to a particular piece of historical data.

The Git idea of a branch is somewhat more flexible than the Subversion idea of a branch. For instance, say I'm hacking away at a new feature, but I haven't thought ahead and created a new branch for my commits. A user then comes along and asks me to fix a bug. In Git, this is no problem, because branches are just references. I first assign a branch to my current work:

    git branch new_feature

Then I rewind my master branch back to before I started working on the new feature, 4 commits ago.

    git reset --hard HEAD~4

I then commit and push the bug fix:

    git commit -am "Bug fix"
    git push

Now the user is happy and I can continue working on my feature. But now I'd like the bug-fix to be included in the history of my branch, since I've pushed the bug-fix but not my new feature. So I change the 'base' of my branch using rebase:

    git checkout new_feature
    git rebase master

Now I can continue working on my branch as if nothing had happened.

Using Git is a bit like having a time machine you can use to alter history so you didn't forget your wallet this morning.

Golly. That took six commands, history unwinding, a rebase, and a few obscure flags. I'm beginning to see your point...how in the world would the lowly subversion user surmount such a catastrophically complicated conundrum without the raw power of git to save him?

Hmm....

svn copy ./my_code ./my_new_feature; cd ./my_new_feature

...hack hack hack...

(user interrupts! a bug! oh noes! must fix!)

cd ../my_code

...fix fix fix...

svn commit -m "fixed a bug! i rock!"

cd ../my_new_feature; svn merge -c HEAD ../my_code

...hack hack hack...

Oh well. Guess it wasn't that hard, after all. Nevermind.

I think you're missing the point. In your workflow, you create the branch before you started work on your new feature. In my Git example, I created the branch retroactively.

If you were to attempt the same feat in SVN, it would get a little messy. You'd have to first roll back the repo:

    svn merge -r HEAD:96 http://server/my_repo
    svn commit -m "Reverted last 4 commits"

Then create the branch and merge in the previous commit:

    svn copy ./my_code ./my_new_feature
    svn merge http://server/my_repo/my_code@100 my_new_feature
    svn commit -m "Imported reverted commits to new_feature"

Then make your changes:

    svn commit -m "Fixed bug"

Then merge your change into the new branch:

    cd ../new_feature
    svn merge -c HEAD ../my_code
    svn commit -m "Merged bug fix"

And once you've done all that, your commit history looks like:

    A
    B
    C
    D
    Reverted last 4 commits
    Imported reverted commits to new_feature
    Fixed bug
    Merged bug fix

Whilst in Git:

    Fixed bug   <- master
    A
    B
    C
    D           <- new_feature

Now, obviously you'd never actually do all this in SVN if you were sensible, but that's exactly my point. The Git concept of a branch being a reference to a commit is more flexible than the SVN idea of a branch being akin to a directory. Things that are perfectly natural to do in Git are rather more complex to do in SVN, and leave behind a messy history of merges.

I'm not missing the point -- I'm saying that your point is silly. You're fixated on doing everything in the same directory, when in fact it's far easier not to do it that way, and the only argument you're making for doing it that way, is that it's more "flexible". But flexibility is not a virtue, unless you need the flexibility!

"obviously you'd never actually do all this in SVN if you were sensible"

Exactly. You'd never do it. You don't need to do it. You can get the job done without doing it. And that's what matters.

Git fanboys are hilarious sometimes...every argument is made from the position that none of the rest of us really understand git, and that if only we did, we'd fall in love with git in all of it's fiddly glory. What they miss is that many of us hate complexity, and we avoid complexity that doesn't justify itself with true functional advantages.

I like simple tools that get the job done. Git makes my life harder; I have to think about more things to do the same, basic tasks that were made trivially easy in subversion. That's the point.

I'm not claiming that Git is better than Subversion, or that you should use it. I'm merely pointing out that branches in Git have other advantages as well as being faster.

The fundamental problem with Subversion branches, at least in my view, is that you have to know ahead of time that you want a branch. Perhaps this isn't a problem for you, but it is for me. Sometimes I find myself thinking, "Hang on, is this really the right way to solve this problem?" In Git, I can save my current work in a branch, trot back a few revisions, and try a different approach.

In contrast, Subversion encourages a largely linear style of development. I expect some people, like yourself, prefer this approach, finding it conceptually simpler. And that's fine; I'm not saying that's wrong or bad, or that you should stop using Subversion. That's clearly what you're most comfortable with.

But a linear development model isn't for everyone. Those of us who like to experiment and backtrack tend to develop in a tree-like fashion, branching off shoots all over the place and pruning the ones that turn out to be a dead end. For this style of development, Git's branching model is significantly better than Subversion's.

To clarify: I presume you're saying that git is much simpler to set up. Which it is.

I think the git repository model is pretty much a clear win over the svn repository model.

Subversion would be better off writing a front-end on top of git. The subset of a repository issue is indeed something that git still doesn't handle very elegantly, but I think ultimately if the right front-end was built, the underlying git repo model would prove better even for this case than the subversion model.

It seems like the issues described there can be dealt with in Git by dividing things up into submodules, if submodules work well. (I haven't used them much.) They also only seem to apply to really big projects — dozens of contributors, and dozens of gigabytes to terabytes.