configure and sfslite

OK, I wasted the better part of an hour figuring this one out. I'm building sfslite-0.8 for use with Chord. It requires the GMP library. But configure reports the wrong error when you're building the thing. To use with chord, it recommends you use these parameters to configure:

../sfslite-0.8/configure --with-sfsmisc --with-dmalloc 

Which on my system (with GMP installed) gives:

checking for GMP library... checking for gmp.h... yes
checking for libgmp... configure: error: Could not find gmp library

Adding --with-gmp=/usr/lib changes nothing. Google finds nothing. Checking GMP manually and it seems to be fine. Finally, after looking through the log files I find the real error: GMP is fine, but dmalloc's not installed! The GMP test depends on gmalloc, but dmalloc wasn't tested earlier.

Removing the --with-dmalloc line fixes the problematic symptoms.

The root problem problem is the ordering of dependencies in configure, though. Bah.

Hacking direct-debit checks

A little story, with two halves.

First half: One of my roommates is somewhat disorganized. After holding a check of mine from June to mid-October last year before cashing it, we came to an agreement. He would have two weeks to cash checks written to him, or would eat the cost. I'd typically write "VOID AFTER (date)" and give him to the end of the month.

Second half: WAMU lets certain companies do direct debits from checking accounts, regardless of whether the customer has authorized them to do so. For example, SDG&E and Time Warner. This has always irritated me, because I don't get the checks back and I can't even see the check image online. All I get is the number, and there's no paper trail.

Putting it together: February 3rd I wrote the roommate a check for my portion of the cable and phone bill-- $22.45-- and wrote "VOID AFTER FEBRUARY 28th, 2007" in big letters up on the top. Sometime mid-March I wrote off the debt. May 21st a charge appears on my account: "TIME WARNER-SAND CHECK PYMT (number)" for $22.45.

WTF?

Well, it turns out the roommate had accidentally mixed up checks sent to the cable company-- and they cashed it! Not only was it not made out to them, but it was void three months prior! But the charge went through, because nobody at WAMU actually verified anything.

Moral of the story: if you want perform invalid transactions, forge checks, or other illegal behavior, Time Warner is happy to launder your money.

And the roommate's actually going to refund me the dough so I'm not going to go bitch and moan at the companies involved here-- although it would be interesting to try and track this all down.

Subversion vs. CVS

I recently decided to take subversion for a test drive. I know a couple folks who are using it and were pleased, and I was tired of some problems with CVS (e.g. having to hack the repository by hand for moves, stupidity with binary files, the pollution of my file namespace with "CVS" directories, ...).

Short version of the result: steep but short learning curve, immediate vast improvement in productivity over CVS.

Longer version:
The "CVS to SVN" howtos don't tell you some of the info you really need to know.

1. Subversion makes an explicit distinction between data and metadata ("properties", in svn). CVS uses .cvsignore files,
   SVN uses svn:ignore properties which you have to set up yourself. This bit me in a weird way-- I had put some JPEG files into CVS but forgotten to set -kb so they became corrupted. I noticed this during my check of files after importing into subversion, and copied correct versions over the corrupt ones in my working subversion directory-- but committing did nothing. This is because subversion helpfully set up file properties for these files that marked them non-binary; these had to be removed using

   svn propdel eol-style
   svn propdel svn:keywords

   before fixing it up with

   svn propset svn:mimetype application/octet-stream file.jpg

   Then, it works correctly.
   
   
2. Subversion doesn't have modules. In CVS I had a separate directory in my CVS root for each project, and could check out and commit independently. Importing this into subversion makes one repository, and committing to one project bumps the revision number on the entire repository. There's nothing technically wrong with this, but it's confusing-- when you 'update' a project and the revision number goes up, yet nothing has changed. To get the same behavior as CVS, you need to create separate repositories for each independent project.
   
   
3. Subversion doesn't like man pages. Everything is via [command] help. This is just annoying because you can't get all the info in one page to search through, you have to interact with the program's help system.
   
   
4. Subversion's repository can only be mucked around with through commands, or worst-case through a text file dump of the same. At some point, I guarantee you will have to hand edit a dump file. You will need to learn their syntax (which isn't so bad) but it's not like going in to CVS and doing file operations.
   
   
5. Subversion likes URLs for some commands. Even if you're running on localhost. And they're not too consistent on when to use one, and when another. This kills tab-completion on my shell. Annoying.
   

But once you get beyond that stuff you find it's pretty slick.

• Moving files is possible-- restructuring your source code tree is easy rather than darn near impossible.
  
• Branching is trivial.
  
• Your checked-out directories are 'clean' (no CVS directories).
  
• You can do lots of things disconnected due to the file caching mechanisms.
  
• Atomic commits.
  
• Vastly improved logging mechanisms, log-per-commit.
  
• Status checking.
  
• Knowledge that the tool has active developers and is only going to get better rather than die a slow painful dragged-out death.
  
• "Coolness" factor.