Distributed Version Control is here to stay, baby

Such is the life of hipsters.

"stab SVN/CVS in the back"???

I'm not sure why you're borrowing an assassination metaphor to describe someone's shift in technology choices. Technology aren't people.

That's just life in technology as the tools improve.

1) Stop manually backing up versions, that's error-prone. Use RCS!

2) Stop using RCS, it doesn't scale. Use CVS!

3) Stop using CVS, it's too complicated. Use SVN!

4) Stop using SVN, it makes it hard to merge branches. Use Hg/GIT!

... And someday, we'll be saying 5) Stop using Hg/GIT. They ________. Use _______!

Same thing for hardware, and languages, and frameworks... and just about everything. shrug

It really still depends on your use case. At my day job I advocated switching from SVN to HG and the change has been great - now we "branch" and merge constantly and it really helped our processes. On my iPhone game at home I still use SVN with beanstalk.com and it works great.

It is great, but I actually think it's a little unfair. CVS was better than directories with date suffixes, and SVN was better than CVS. Git sounds better than SVN.

But to me, SVN isn't one of those technologies that I'll look back on and despise. Sometimes you look back on a technology and wish it had never existed (the original EJB seems to inspire this in some people), sometimes you look back on it and see deep flaws but still have respect for it as a first crack at a problem (some people look on the original Struts framework this way), and some you look back on fondly even if you no longer personally use it (a lot of ruby/python folks seem to look back on perl this way).

To torture the analogy, I'd say SVN is a moderately effective antibiotic that has been replaced with a more effective one that has fewer side effects. But a leech? Come on, it was a good technology.

Old technology that has been surpassed should be stabbed in the back. That doesn't mean the old technology can't be appreciated, just that it's place in the world has changed.

Nobody is driving 55 Chevy's around anymore. Some people dedicated aspects of their lives to appreciating the time and space when that technology was dominant, but their glory days have passed.

So has subversion's.

A version is just a changeset, so for me, it makes little sense to claim "changes" are a completely different way of thinking than "versions".

Perhaps it comes down to how you divide work up. I just don't like branches. They're mess.

I think in this case a version is the changes along with the base they're applied to. Whereas a change set is a difference between 1 version and another. like a diff or delta.

I don't think it matters as much how we think about it. What matters is that the implementation of the VCS "thinks" of them as changes, which results in the easier merging.

Once upon a time I designed a versioning system for an object graph. It was for an application framework that was meant to be designed in an IDE, and didn't have source code, per se (it did have little snippets of code). But designing it around graph deltas, rather than versions, was always the right thing to do: that much was self-evident.

Even as I use svn today, I turn almost all my work into patches. For every bug I fix and every feature iteration, it gets turned into a patch. That way it's usually pretty easy if I have to apply it to an older branch for a hotfix or whatnot.

I don't really get that part, at least not with the way I use svn. I branch, I tag and I use patch sets, which have some similarity to changes. I read this bit http://hginit.com/02.html from Joel's Mercurical intro, and it sounds a lot like how I use svn, except that the branches are on the server, so they are probably a little slower, with the positive tradeoff of being available to my team. The other bonus with dvcs is having local history without doing pushes, which I think is a bigger selling point (although I get something similar from my IDE).

I generally hew to the extreme programming view of branching and continuous integration. Push early and push often. Browsing github, I seem to find a preponderance of projects where the branches are never push-ed back to a master copy. No matter what tool you are using, branches can introduce semantic changes that are hard to merge.

To sum, DVCS not that big of a deal for the way many people already use CVCS, when you end up working with a centralized copy anyway.

He explains it more in the linked "HgInit" tutorial. An excerpt:

Mercurial actually has a whole lot more information: it knows what each of us changed and can reapply those changes, rather than just looking at the final product and trying to guess how to put it together.

For example, if I change a function a little bit, and then move it somewhere else, Subversion doesn’t really remember those steps, so when it comes time to merge, it might think that a new function just showed up out of the blue. Whereas Mercurial will remember those things separately: function changed, function moved, which means that if you also changed that function a little bit, it is much more likely that Mercurial will successfully merge our changes.

It doesn't. Joel is a little bit off base here, in that it makes no difference whether a VCS tracks snapshots or deltas. What does matter is whether it keeps track of merges. If you merge one branch into another, your VCS must record that information, so that future merges can be done correctly. SVN doesn't do this, Git and Mercurial do. (And note that Git stores snapshots, not changes.)

Joel's absolute right about one thing, though. Being able to merge correctly and reliably make a huge difference. It's what makes the distributed part of DVCS possible. Without a central repository, branches happen a lot more often, and merging has to work right. The contortions that teams go through to prevent branches are a thing of the past.

The storage model does not - it is not file-delta based, like SVN and Mercurial. However, you as a developer can (and often do) think of the commits in terms of a changeset or "work introduced" - this is evident in tools that exist like 'rebase' which treats each commit in a branch as a patch and the collection of unique commits on that branch as a patch series and helps you transfer that series elsewhere. The 'cherry-pick' command is similar - it enforces your thinking of each commit as a changeset or patch to what came before it.

I don't think that link contradicts Joel. Git represents repositories as a network of diffs, not a linear history of versions.

It often makes sense to have 2 alternate implementations of a component in the same codebase, so you can switch between them at startup/during runtime, and compare them side by side. Something that isn't as easy to do if you create 2 separate branches.

Feature flags are usually just a poor-man's way to separate development (changing) and live (stable) code branches. They have explosive complexity (2^n combinations need to be tested). They require you to contort your code unnaturally to minimize the number of conditionals.

What he's talking about is branching in code to avoid all subversion branches. That's probably pathological.

He implies in the last paragraph that it's his final post. Still, I think there's a point here. Writing, when you're that good at it, isn't so easy to give up. Also, the blog has been a huge part of Spolsky's success. So I bet he'll revive or continue it in some form before too long.

Edit: I hope he does, too. I probably disagree with him more than half the time, but there are few other writers on software who consistently hold my attention, and almost no one who consistently makes me laugh.

Try out git. Force yourself to use it for a few weeks. I didn't like it at first. I used to be a Mercurial guy until I really learned git. I still don't know what it is, but there's something about git that just makes me want to love it.

I can say without hesitation mercurial or git will be insanely faster for these operations. Remember, you work locally, and then push with hg/git. So when you do "git commit" it only relies on the speed of your hard drive/cpu. Commits happen instantly. Updates are needed very rarely (since you don't need to update to make new commits). Merges are so much faster it's not even funny. After merging in hg/git you wonder why SVN even had a merge functionality.

In addition to those conceptual differences, the actual act of transferring files between remote and local on git/hg is also much faster than SVN. Entire checkouts of git repositories are usually smaller (disk size) than the equivalent SVN checkout... of one version. This means less time on the network all around.

Binaries are not merged - if histories diverge and one side changes but the other does not, it will choose the side that changes. If both sides change, it will record a conflict and you have to choose one side (or create a new binary that you tell the system is resolved). You can run an external merge tool with 'git mergetool' and there are over a dozen it knows how to run, but I don't know which of them will handle images. You can also use .gitattributes to help you diff binary files efficiently, but you still have to either choose one side or manually create a new binary. I mean, even a merge tool won't help much there - if you have images that changed on two different branches and you want to combine them, you have to fire up Photoshop or something anyways - that's almost always going to be a manual process. Though, in the four or so years I've been using Git (and the years before that with SVN and CVS and RCS) I don't remember having to do that very often - thus is the life of a coder, I suppose. The people who create and modify images for programs tend not to tread on each other.

Also, this is really the same problem even for systems without solid branching capability, like SVN. If two people modify a binary image at the same time and one commits, then the other will get a merge conflict when they update and will have to solve the conflict in order to commit.

I think it's the last one. Tweeted 5 minutes ago by Joel (http://twitter.com/spolsky/status/10671213571):

"The last Joel on Software article[...]"

Not at all! Today is the ten-year anniversary of my first real post, so I've been planning to have my last real post on 3/18 for a long time.

Thanks for all your attention over the years. I'll still be around, just not doing these essays any more.

I thought the same thing, but to his credit:

"I announce my retirement from blogging effective March 18th"

Blogging is hard! Let's go Shopping.

yup.. seriously why so many points? common editors/superusers...

Agree: Upvote, Disagree: Downvote. That shouldn't be the way to go. I insist the article is novice advice. At least take the time to reply on how you find it original rather than simply downvote.