Is using distributed source control like Mercurial worthwhile for a team of one?

I currently use Subversion for my one-person software company. Is it wor开发者_如何转开发thwhile moving to Hg (Mercurial)? Or are the benefits only realisable with a multiperson team?

I think it's worthwhile, even for a single person — but I'm sort of biased since I'm a Mercurial developer :-) Even if you never branch and merge, Mercurial is a better Subversion for the basic operations like commit and tag:

• hg commit: very fast so you'll tend to make more fine-grained commits than with Subversion. A commit is also truly atomic in Mercurial since we have no mixed revisions. I count that as an advantage, but people may obviously disagree here.
• hg tag: points to a specific point in the history, not a copy under /tags. The problem with Subversion tags is that the copy may or may not be identical to how /trunk looked at a specific revision. Subversion really has no built in tags, and while emulating them, it's possible to mess up in ways that you cannot do in Mercurial.

Because Mercurial is so fast, people are using it in different ways than you would use Subversion. A good example of this is hg bisect. You use it to find the first revision where a particular error is present. It works by binary search, where you halve the search interval in each step. You could definitely do this with Subversion too, but there are no built in support for it and it would be slower because you need to contact a server over the network.

The record extension is another really nice feature of Mercurial. It lets you commit only some of the modifications inside a file. This is nice since it lets you make small and self-contained commits.

From my experience , Git and Mercurial are currently more suitable for open source project or small team or single person team. So, in your case, I would recommand them. Subversion is more suitable for big organizations that need centralized repo and more fine-grained access control.

Almost anything is better than using Subversion IMO. I like Mercurial (hg) and Darcs, but my favourite by far remains Fossil for personal projects (as well as shared). With one binary and one file per repository it's easy to keep track of my work, easy to back it up, easy to move it around, etc. Further, the built-in wiki allows me to keep my brainstorming together with my sources, the ability to check in my documentation (generated or otherwise) and access it through the built-in server puts all my work in one place and the built-in issues tracker lets me keep a running history of what I've worked on or need to work on in the future.

Oh, and Windows isn't quite as much a second-class citizen with Fossil as it is with a few other DSCMs I can name. (I'm looking at you here, Git.)

I would strongly recommend you reading hginit. It is a great tutorial for Hg and there's a chance that after reading it you will be sold :-)

Yes it is. Despite the 'distributed' designation of mercurial, I would argue its especially good for a lone developer. You get similar features to SVN(plus a lot of other ones) but in general they work better and faster. Setup, backup and maintainence of the repository is much easier. It was designed to allow many lone developers to work together so many features are useful before you need to work with someone else.

My favourite advantages are simple copy-paste backup, and the ability to clone the repository for an instant 'sandbox' environment. I'm a bit scatter brained so its nice to be able to spawn a new environment, try out an idea and decide if I want to integrate it into the main codebase. I can do this without disturbing the original task I was working on.

When I first switched to hg, it was a constant feeling of 'oh..that works a lot better then svn'. At this point I would not consider SVN for myself or with a small team and would only consider Mercurial, Git or similar DVCS.(I do prefer mercurial though)

one advantage is that you could work offline, like when you're coding at the customer without a connection to your source control server. how often do you do that?

otherwise i'd just stick with subversion. if you need them, learn how to correctly use release- and feature-branches. there's no reason to move to hg for that, even if hginit tells you how bad subversion is ;)

I'd recommend definitely using revision control for solo development. It doesn't matter too much which you use, SVN, Git, Hg, etc. The reason why is that it allows you to rollback in the event of regressive bug, loss of code, corruption, and of course branching and merging capabilities (you should always develop in a branch and only merge with trunk when the new feature/bug is full tested), etc. All these things (and more) you won't be able to leverage without a version control system.