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.

What makes this work so easily is the fact that Darcs stores everything in one _darcs directory instead of the SVN / CVS approach of throwing files in every single directory. There are a ton of reasons to use Darcs (or it’s competitors) when working in a corporate env (even one that uses SVN / CVS) but my favorite is that you get the full benefit of version control on all your work and can check in all the buggy crappy unfinished code you want without polluting the central repo that affects other developers (until you want to). It’s my practices to do a checkin when I leave work every day, no matter if I’m finished with what I was working on or not. With Darcs it doesn’t matter, because I won’t break anyone elses unit tests because it’s just my personal version control system that’s effected. When I’m done with whatever I was working on and it passes all the tests I can push it back out to other developers. Along the way I’ve been able to make as many revisions of the files as I wanted to without screwing anyone else over.

Sneaking darcs in under the radar:

For those of you who have to use Subversion / CVS at work sneaking Darcs in for your personal benefit it trivial. Just follow these steps for each branch (in svn / cvs ) that you need to work on.

check out a copy of the branch / trunk / tag / whatever that you’ll have to coordinate with others.

assuming you want to version control everything that got checked out you’d cd into that directory and

1. darcs add -r *
2. darcs record -am “Initial Import from svn version XXX”
3. Don’t worry. Darcs is smart enough to ignore all of your subversion files.

From now on whenever you want to start working on something for this branch you just move to wherever you want to checkout a new repo for a feature spike / bug fix / whatever and do a “darcs get”

Use Darcs as you normally would, checking in whenever you want without worry.

When you’re done with your feature spike / bug fix / whatever do a “darcs push” back into the dir where you started, then cd to that directory and do a " svn commit -m “some comment here” " (remember you haven’t added the _darcs dir to svn so you don’t have to worry about it getting checked in).

Snicker in the knowledge that you’ve beaten “The Man”.

Combining forces for everyone:

So you’ve convinced everyone to use Darcs. Yay, but for whatever reason you’ve decided to keep SVN. Just follow steps 1-5 above. You could theoretically check in your _darcs dir but I suspect that might just lead to more headaches than it’s worth, especially when you consider how easy it is to create a new darcs repo (steps 2.1-2.2) and the fact that you only have to do this the first time you check something out, which is to say, almost never.

If you’ve tried checking your _darcs dir into svn please add a comment so that I, and others, can learn from your experience.

[Update] Related posts:
Using Darcs with SVN / CVS Flow Chart

Why you should be using a distributed source control system