Tales from the darcs Side

I like darcs. I've only been playing with it for less than two weeks, but I find that it fits my criteria for a great versioning system: a) it works, b) it can be installed on a variety of different systems via a process I can handle before I've had my caffeine in the morning.

Advantages of darcs over Codeville: for most popular platforms, a pre-compiled binary called either "darcs" or "darcs.exe" is available. If I were to install Codeville, I'd need to first install Python, then Python's BerkeleyDB bindings, then the Codeville package. If Python breaks, Codeville breaks.

Further advantages of darcs over Codeville: Codeville is very much a "trust us, we know what we're doing" system. Your changes are stored in a complex system of database files with names like "log.0000000001", so if you ever want to peek under the hood, you'd best bring your spelunking gear. darcs seems a little more clear-case about how and where it stores its fiddly bits. Not that I recommend you fiddle with them, per se, but its design lends a distinct advantage to darcs that I was never quite able to capture through Codeville: file-based repository duplication.

In a nutshell, this means that making a copy of your darcs repository is as easy as typing "cp -a ./darcs_dir1 ./darcs_dir2", and if I were so inclined, I could scp or rsync changes from one system to another without worrying about losing the repos. I've tried (and failed!) to copy Codeville's .cdv directory to a new system, rebuild the OS of the host machine, and replace the .cdv repo back to where it belongs. End result: I lost my data. Something about the way Codeville handles its BerkeleyDB innards means that if your chicken bones aren't lined up just right, the repository won't be consistent. darcs does not seem like it would eat my files were I to try a similar stunt with it in the future.