I would add that Distributed Source Control has another advantage over branching/merging. In branching and merging you have to decide on the structure of the branches. For instance my branch “Foo Feature” must merge to “Trunk” (where Trunk = testing), and then Trunk will merge with Release when it is released. That means that if Foo feature is merged to Trunk, and then management decides that Bar feature should be released next, you are in a difficult spot.

With distributed source control, the decision isn’t needed. You, in a sense, create the testing branch each time you want to start testing with all the features you want to include in the next release since any branch in a distributed source control can merge with any branch.

With Team System, I find the delay before editing as it checks the file out annoying, plus it really is only feasible to use Visual Studio (or Eclipse if you paid enough), since manually checking out a file to edit is way too time consuming. There are also difficult merging scenarios — like creating the same file in two branches and then merging them together.

With SVN, I find it annoying I have to jump to SVN to handle file renames. Folder renames are even more difficult.

With Mercurial, I can make *any* change to the files, and then when I’m ready to commit, Mercurial can handle any change. It equally handles any merging scenarios like creating the same file in two branches and merging them together, and if the files are identical, it automatically resolves the merge.

All of these Mercurial features allow me to write code ignoring source control until I’m ready to commit.