weblog.masukomi.org

Using Darcs WITH Subversion / CVS March 29, 2007

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.

1. check out a copy of the branch / trunk / tag / whatever that you’ll have to
   coordinate with others.
2. 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.
   
3. 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”
4. Use Darcs as you normally would, checking in whenever you want without
   worry.
   
5. 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).
   
6. 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

Popularity: 9% [?]