Nat!'s Web Journal

Lookin past CVS

I am debating with myself, if I want to use arch or Subversion.

My sympathies are currently with arch for the following reasons:

1. The backend is standard UNIX tools, patch, diff and tar and your file system. No Database!
2. Has distributed repositories. That looks really nice, as a central repository, that may not be available at all times, can be a pain in the ass.
3. Author appears to know, what he's doing: Read this criticism of the development of Subversion. I think some of the observations are good like these two:

   Well, that's the problem with some design patterns like attaching property lists to everything under the sun: they don't really solve design problems but they give you an operational language in which to _restate_ design problems.

   and

   The problems are: (1) unless you have at least one fully worked design for how to implement your API, you shouldn't have any confidence that good implementations can exist; (2) unless you have at least two fully worked designs for how to implement your API, and they make usefully contrary trade-offs, you should really start to wonder whether doing extra work to make an abstraction here is the right way to proceed.

Things that make me suspicious about arch:

1. Single file commits, without committing the whole tree are considered a "special" case. I don't want to adapt my developing style to the tool. (See also: Software Adjuvant)
2. May or may not cope well with whitespace in filenames.
3. Possibly too slow with Mac OS X, though I don't know what a revision library is yet:

   Accessing hardlinks on HFS+ is approximately an order of magnitude slower than accessing regular files. This has fairly serious performance implications if you plan on using a revision library with tla.

4. Rebuttal to above criticism :) Not quite as clever though.
5. Small user base. No nifty GUI tools like TortoiseCVS.
6. Didn't see offhand any support for $Id$ and $Log$ for in-source expansion
7. Doesn't work well on WIN32.
8. Data is stored in gzipped tars. Not exactly the most failsafe format.

Also quickly looked at monotone, which uses an embedded SQL database, which is not to my taste.

darcs and arch, not on 10.2

I want to try out darcs as an alternative to arch at work. darcs appears to be just as powerful as arch and has a simpler interface, which I'd prefer. I didn't mind at first, that it was written in Haskell - which is a language, that looks like Wirth got hold of LISP and tried to fuck it up as much as possible.

Then I minded! The problem is, that to get ghc the Haskell compiler running... you need to have Haskell running.

Then an alternative appeared: Use Darwinports. Installing that over CVS took at least an hour. Then I tried port install ghc. It failed with a compile error. 10.2 with gcc 3.1 is just not up to the task of compiling ghc. I didn't have gcc 3.3 installed there for whatever reason.
Then I tried fink. I looked at the package list on the fink site and saw ghc there. It took a while, until I figured out, how to get the whole package list into fink, but then ghc was missing in the downloaded list. Read a little something about stable and unstable packages on the fink site and consequently I gave up.

I quickly made up my mind, that this was not going to work, so I figured I had to use arch anyway. Unfortunately that failed to compile as well, with gcc 2.9 or gcc 3.1. So it seems that I can't use either with 10.2 or must install gcc 3.3. I finally pussed out and decided, that for EOF I just need 10.3. I booted that up.

Now I am runninng port install ghc again on 10.3 and it is going into its third hour for building ghc on my G5. This all reminds me of a short story somehow, that Harlan Ellison wrote and that he named "I Have No Mouth, and I Must Scream".

I am trying to use darcs

From my current rather naive point of view, darcs looks like a dumbed down version of arch. Which is good, because it's easier to start being productive with. I kinda expect, that after I have worked enough in darcs I might want to switch to arch afterwards. But then maybe not, if arch doesn't buy me much more.

Here is an interesting article from Mark Stosberg, who switched from cvs to darcs.

Problems I encountered with darcs so far:

1. Remote repository system needs darcs installed. arch doesn't need that. Installing on FreeBSD was easy though, thanks to ZNeK. This may turn out to be quite a problem, as you need to install a cgi-bin script for anonymous remote access. That's just trouble waiting to happen. There is an experimental project underway, that does away with this limitation called darcshive or maybe darcs-repo.
2. Removing files that you added by error (f.e. .AppleDouble and Contents), is not quite as convenient as hoped.

Getting a remote repository going is fairly easy. Just create an empty one with darcs init on the remote machine and with darcs push user@hostname:/path/to/repository you sync it up from the local machine.

Matrix Sports

Pole Vault and Ping Pong Might be a little bit older, but I just found them. Check'em out.

Off darcs again. Some corrections on previous stuff.

So I gave darcs a try. I think the way it handles repositories is really good, as darcs doesn't organize them. That's left up to the user. This simplifies the user interface and the concepts to learn a whole lot. I expect to give darcs another look when a 2.0 release is announced. I am not going to use darcs now, because of one single event, which turned me off completely. I can't reproduce it, but it went something like this.

I created a repository at home and synced it up with the remote server. Then I added some files locally but forgot to push them up. At work I pulled the remote servers repository down and saw that I missed all my files. As I had them at work also, and also slightly improved, I added them locally there and pushed them up. When I came back home and tried to pull in the changes, darcs just hang.That's just something I don't want to happen three months down the road.

An architectural problem with darcs is, that it holds apparently everything in memory, so for big projects it would read the whole repository into RAM, for some operations. That's not very impressive.

I got a nice letter from Mark Stosberg, which made it neccessary to correct my previous entry Looking past CVS and he turned my attention to the "baz" fork of arch. Bazaar as it's called is a modified version of arch, that is soleley dedicated to improving the user interface. I am going to check this out over the weekend.

How to build bazaar on Mac OS X

You need to install the following packages before installing bazaar: diffutils, gettext neon expat.

Here's a copy/paste was to install all the stuff in /usr/local:

curl -O http://belnet.dl.sourceforge.net/sourceforge/expat/expat-1.95.8.tar.gz
gnutar xfz expat-1.95.8.tar.gz 
cd expat-1.95.8
sudo ./configure --prefix=/usr/local
sudo make install
cd ..

curl -O http://www.webdav.org/neon/neon-0.24.7.tar.gz
gnutar xfz neon-0.24.7.tar.gz 
cd neon-0.24.7
sudo ./configure --with-ssl --enable-netrc --with-expat --enable-shared --prefix=/usr/local   
sudo make install
cd ..

curl -O http://ftp.gnu.org/gnu/gettext/gettext-0.14.1.tar.gz 
gnutar xfz gettext-0.14.1.tar.gz 
cd gettext-0.14.1
sudo ./configure --prefix=/usr/local
sudo make install
cd ..

curl -O http://ftp.gnu.org/gnu/diffutils/diffutils-2.8.1.tar.gz
gnutar xfz diffutils-2.8.1.tar.gz
cd diffutils-2.8.1
sudo ./configure --prefix=/usr/local
sudo make install
cd ..

Now download and install bazaar. As this is still experimental software, we grab a new export from the source directory. So if below link 404s out, look for a newer release in the source directory:

# possibly gone, at the time you're looking
curl -O http://bazaar.canonical.com/packages/src/bazaar_1.1-~200501081143.tar.gz

Now apply the magic Mulle patch and make.

# currently this patch is needed. It adds -lintl -lneon -lcrypto -lssl -lexpat to the list of linked libraries
curl -O http://www.mulle-kybernetik.com/software/bazaar/patch-bazaar-1.1-nat.gz
gnutar xfz bazaar_1.1-~200501081143.tar.gz 
cd thelove\@canonical.com---bazaar--devo--1.1/
cd src
cd baz
gzip -d -c ../../../patch-bazaar-1.1-nat.gz | patch -p1
cd ..
mkdir =build
cd =build
# for sh and bash this works
PATH="$PATH:/usr/local/bin"
sudo ../configure --prefix=/usr/local --with-gnu-diff /usr/local/bin/diff --with-gnu-diff3 /usr/local/bin/diff3
sudo make install
cd ..

Revision control system conclusion

So I have spent quite some time looking at a few next generation software revision systems. Here's what I have come to conclude about each of them:

• arch/bazaar - arch promises to be a distributed revision control system. But it is so only in a limited way: mirroring. It would be possible to use arch to build a truely distributed system, but that means a lot of work. It's mainline successor bazaar, improves on the user experience. The roadmap for arch 2.0, doesn't look like it's fixing any of the conceptual problems of arch. My impression is that this software is going to die off eventually, as it doesn't deliver enough to offset its bondage and discipline traits. Other systems will leapfrog it.
• codeville - I read the slides and think it could become interesting as it tries to be fairly cvs compatible and also tries to do merging more cleverly. Unfortunately it uses Berkeley DB as the back end. It can't do per-hunk commits. It needs a running server process.
• darcs - darcs does pretty much everything right. From the way you can truely push and pull and edit changes between repositories to the per-hunk commit and rollback feature. darcs could be the future, alas it is not the present. Written in Haskell it has serious performance problems and bugs, that make it useless to me at current time. My hunch is that darcs won't ever really manage to work without "hanging" as it tries to resolve conflicts. But I will give it some more tries as it progresses.
• monotone couldn't get this to install on Mac OS X. It uses a database backend. As I couldn't test it, I am not sure how well the distribution mechanisms work.

So what now ? I am currently back to CVS. I will monitor the progress of the various systems. I hope darcs can push through, but I don't bet on it. My ideal would be a darcs with an arch backend. Maybe bazaar will be able to deliver something close, but again I don't bet on this either.

UnitKit

I haven't used any kits for testing my code yet. I usually have a bunch of little test projects lying around, that I use to test my code against. The idea of a test kit, that would help write me these tests, was something I wanted to try out.

I looked around various sites and by recommendation narrowed the number of candidates down to UnitKit and OCUnit. OCUnit seems to be far more popular and we even have a test helping framework called OCMock that is at least related by name.

Both Kits work pretty much the same, but I chose UnitKit because

1. failed tests are warnings not errors
2. more convenient macros, that make test writing even less typework
3. very nice looking user guide included

It's not that there's anything wrong with OCUnit, but UnitKit is just a tad easier to use.

Oily paper-writer language

Just read this perl on an IBM site:

Common wisdom suggests that this situation provides an opportunity to refactor your object to make it more test-friendly.

That used to be written as: you need to kludge up your methods.

"Want a real challenge ?" Revisited

[A followup to a previous entry]

I once or twice a year remember to amble over to llamasoft, to see if anything's happening there. As it happens, there is some news, mainly that Gridrunner++ has been released for the Mac.

Russian Linux