Darcs Distributed Version Control

November 6 2009 by B-Drive in Tools |No Comments

In my search for easy to use technology I decided to use the darcs distributed revision control code repository to maintain some of my work-usbstick-website–home files.

What darcs is:

  • It’s an easy to use, distributed, code repository.  It falls into the same category as Mercurial,GIT or Bazaar.
  • Distributed?  Yes, patches are exchanged between repositories and there is no one single “mother”repository.
  • Super lightweight; runs locally, super portable, cross platform, and easy to learn. The download is 4 megs.
  • A great introduction to the world of distributed reversion control.
  • Doesn’t do anything to your existing folder and file structures (non-invasive).

What is a distributed respository?

Hmmm . . .this definition is different depending on where you look.  Even as of this date (nov 6 2009) Wikipedia doesn’t have a good definition.

Here is my definition:

  • Not tied to a central repository.
  • It’s faster.
  • Easier to branch.
  • Work offline and still create commits.
  • Distributed backups — everything is a working copy.
  • Collaboration between developers without checking into central copy.
  • It can run locally, easily (especially darcs).
  • Useful if you are working on a module with a small team within a larger team, and want to revision/track changes with each other but not the full build.

I think subversion is a rock solid repository, and quite honestly, I am not a proponent of using technology for its own sake.  The simpler the better. But the future seems to be distributed repositories and maybe with teams working remotely from each other, the advance of SOA, etc. these types of tools will make more sense.  I suggest trying out darcs just because it gives you an idea very quickly what these are all about.

Repository Workflow

  1. Clone a repository to your own repository.
  2. Work in the clone — which is now your working copy.
  3. Check in and out of your working copy from your IDE/cmd line.
  4. When you are ready, commit those changes to another (or original) repository.

One way to look at this is, the “central” repository is the build server’s repository, and you have your own.  But just remember, the only thing central about that repository is that everyone agrees its the place where production bound code must end up.

Maybe this sounds disturbing.

In the “old” days the shops were so used to having copies of everything out of fear of a developer “getting hit by a bus” (which is code for: corporate culture does not trust anyone at all).    Honestly, I have yet to see that scenario. But it does lead us to something I haven’t seen discussed too much:

Best Practices Using Distributed Reversion Control

I haven’t thought about this much until now, but here are some of the guidelines I use for a distributed system.

  • Refresh/rebuild in the morning.
  • Check in when you get a meaningful amount of work done.
  • Physically back up your directories
  • Exchange your patches with your team (distributed backups).

Sometime when working in a continuous build environments, I will check things in with my feature sets turned off . . . but usually not, if they are not ready.  Also, you can keep a backup of workin progress in another of your own distributed repositories on a network drive (in addition to your local).

Back to Darcs
The scenario I describe here would be using darcs to sync files from an html blog between your local machine and a usb stick. Let’s assume you have some files at x:\usb\blog and locally, you want to work on them at c:\local\blog. (I actually use this method for a tiddlywiki “getting things done” piece.)

Download darcs and decompress to a desired location.  Add the directory to your path.

Create your first repository.  Navigate to x:\usb\blog and type:

darcs init

Next, recursively add all the files and folders from there:

darcs add -r *

Notice that it skipped all the _darcs files created from the init command!

Run this:

darcs whatsnew

And you can see all the new files and folders you added. But we haven’t saved yet, we have to do this:

darcs record -a

You get asked a few questions (which can be set on the command line as you get better with the tool) and its all checked in!

Time to get a copy of this repo to the local.

Navigate to c:\local\blog (which should be empty) and type:

darcs get x:\usb\blog

You have a local copy! Make changes in your existing files there (on c:\local\blog) and when you are ready, check in your changes:

darcs record -a

And then run this to propogate those changes to your usb stick — first change directories to x:\usb\blog and run:

darcs pull c:\local\blog

And both repositories are sync’d up.  I wrote a little batch file in my case to automate this.

You are probably wondering why in the world I would want to do such a thing.  Well, I can access the files in my tiddlywiki from several spots, and I don’t want a brute force copy over of the file least I lose information.  I need the granular capability  Also I also use it to branch — for instance at year end — very easy!!!

Of course there are a whole slew of other functions but that’ll do.  Darcs is the simplest tool to get your feet wet in the world of distributed version control.

Comments are closed.

« »