I recently used Darcs with an XCode project. While most of our usages on our projects will be with traditional source projects, I believe much of the experience will apply. I do need to try it out with a more traditional project, which I'll probably do in the upcoming weeks.

What follows are notes I took while using it. My development machine for most of the tests was my powerbook. I had a local _darcs repository in the same directory as my xcode project. I also had a second, backup repository on a 256mb USB 2.0 thumb drive. When I'd "push" my changes to back them up, they were going to the thumb drive.

I'll organize this better soon.

notes

Darcs was SLOW..for this test. A commit with changes in the project causes 300-1000 "patches" to be formed. I think this is due to the fact that each individual grouping is being compared with each other individual grouping, causing an intense slowdown.

I'm not sure if this will improve with traditional projects, but for working with X-Code based projects it just seems way too slow to be worthwhile in the long run.

Darcs seems to excel when you have a project you're working on by yourself;

I'm wokring on a project here in the car. Traditionally, when I've been doing this, I've made a makefile target that tar'ed up the working directory and another that proceeded to copy it to a floppy disk or to a flash thumb drive. With darcs, I simply create a new darcs tree over on the thumb drive, record and push the current changes over to it.

I end up with a checkpoint, a backup, and the changes/patches backed up. It really simplifies things a lot, and makes me feel a lot better about having all of the changes recorded.

I still don't think that darcs works well for ProkectBuilder^?/XCode style projects... but i did just check in a changeset which worked quickly. Maybe something was up before. Today will prove or disprove that thought...

I do like that darcs has a single _darcs directory at the top of the tree, and that when you're below it in the tree, it automatically searches up to find the right directory. This means that if you've got a project ~/src/proj1, the _darcs directory (like the CVS directory) is in there, and there alone. So if you're in ~src/proj1/foo/bar/baz, and do a 'darcs record' to record any changes in that directory, it will automagically search back up the tree to find the _darcs directory to use it.

However, this means that you can't really check out a subdirectory of a project, as far as I can tell. It's all or nothing.

The project is available via web (if the _darcs directory is available via the web) via curl, available via ssh, or local in the directory tree. It comes with a .cgi script to browse the repository, which is nice. The fact that the _darcs directory is all that is needed means that you can just put a few _darcs directories in your web heirarchy; one for experimental releases, one for current releases, ect, and just pull from the 'primary' repository when making the release. ('primary' is really a misnomer, since all copies of the _darcs repo are created equally.

in that _darcs directory, it keeps track of your username/email address as well as the last place you 'push'ed your changes to, so that you don't need to enter that each time. It figures out whether the place you're pushing the changes to is a local directory, a ssh'ed remote directory, or an email address by the formatting. (for pulling changes, it also supports http, as mentioned above.)

When I got home, I took the source tree, with a few thousand patches in it (in just a few .gz'ed patch files) and tried to push it up to the cube via my dsl connection at home, it took upwards of 50 minutes to upload it. The entire _darcs directory is 45mb, and should take no more than 12 minutes, tops, to upload to the machine from home. This seems unacceptable to me.

immediate conclusions

I think that although its slowdown might be due to the fact that xcode makes oodles of little changes. I loaded my xcode project in xcode, made no changes, then saved it out. Darcs then claimed there were 300 changes to be recorded. I moved around a few 'connections' as well as a few controls in the gui layout system, and it claimed there were 1800 changes to be recorded.

While a standard project might not have this many changes per record/check-in, i think it does show what things will be like in a mature traditional project.

I believe that the major slowdown is that it is comparing these thousands of patches with eachother to determine dependancy. I might be able to figure out which files are the real culprits, and tell darcs that those are binary files, and should be just committed in one block.

I checked out the darcs source tree itself over teh intarwebs, and due to the number of patches, it did take a few minutes to apply them.

It's a shame that it is so slow, because it has a lot of really good ideas in it.

-- ScottLawrence - 07 Sep 2005

Second week conclusions

I found some information on the net about how to best configure Darcs for use with XCode projects... basically, it sets a few key file types as being 'binary'. After I made that change, the number of changes per substantial checkin has been a lot more reasonable.

Darcs is just as fast as CVS now for checkins as well as pushes over the net to my central Darcs repository on the G4 cube in my office.

Now that it's configured properly, I seriously like it a lot.

-- ScottLawrence - 11 Sep 2005