If you’ve ever:

• made a commit and then realized you forgot “one little change”.
• made a commit and regretted it.
• wished you could combine some the past couple days worth of commits into one nice combined commit in the main branch.
• wished you could commit just part of a file.
• needed to drop work on one task and switch tracks to another one without having to make commits with unfinished changes, or commits with changes for one issue and a little of another.
• wanted to make a test spike with version control and without polluting the public repo.
• managed an open source project.
• wanted the security of knowing that there was a valid backup of your revisions on many other peoples boxes, or even just your own.
• been frustrated with branch namespacing issues
• been frustrated with how difficult branching and merging is in most centralized version control systems.
• wished you could just create branches to work on a feature or a bug without worrying about the consequences to the main repo.
• wondered which branch a bug applied to.
• wanted to use version control when you were offline.
• wished you could quickly compare versions of entire trees.
• wished you could easily release everything in the current branch “except that”.
• been concerned about how to scale a system to support hundreds, or thousands, of users.
• been concerned about what would happen if your main repo box died.

…then distributed version control is worth your consideration.

Using Darcs with Subversion / CVS

Some of you have gotten the distributed version control religion (If you haven’t, you should read my Best Practices essay) but are stuck with Subversion (or CVS) either because that’s what they use at work or because some part of your deployment systems use it. You may also want to combine them simply because of the power of svn externals which lets you pull in some of your code from constantly updated , Subversion Based, 3rd party repositories. Using SVN with a distributed version control system also gets you a cannonical, no doubt about it, central repo, instead of just a repo that everyone agrees to call the central one, plus you can utilize all those nifty notification and stats tools people have written for svn.

I was reading some articles yesterday that finally made the light bulb go off about distributed source control management (scm) and why we should be using them. First off, a distributed scm, unlike CVS or Subversion, has no central repository that all others pull from. It’s possible to set one up and say that it’s the master and tell people to pull from and push to it but that’s more a matter of convention. What’s truly unique about these systems is that each checkout is it’s own self-contained ecosystem. And there are many reasons this is a good thing: