art taylor

Sometimes it's good to think twice, but those who know me know I just consider that a waste of time. Measure once, cut thirty times, that's my motto.

I was pondering the Subversion problem I was having last week, and realized that I could solve the problem with some disgusting and brittle hackery.

According to the doco, Subversion repository copies are very inexpensive, basically being copy-on-write links, like those short-lived CD-based overlay filesystems.¹ Tags, therefore, were especially lightweight, with an O(n) disk footprint based on the number of files in the "tag". Remember, these aren't tags, but rather, someone's answer to "How would we implement tags if we only had a filesystem?" It's the equivalent of a symbolic link farm, but more efficient.

This, combined with the retarded svn merge concept (which they admit now to be nothing more than "diff and apply") allowed me to cobble something together, using the second-nastiest shell scripting I've ever done. Witness the following diagram.

It's basically the same as the previous diagram, with one modification. As Branch 1 is created, a snapshot is made of Trunk at the same time. I might pick a name like [branch]-latest-trunk-merge-point but it could be anything.

As the developer working on Branch 2 (reduced in detail as it is here merely for illustrative purposes) merges up, he creates Trunk version t1.1, necessitating a merge down to Branch 1. Just doing a merge would create all kinds of havoc, possibly overwriting or deleting files added or modified on Branch 1. Of course, one could just svn revert, but it's the well-known pain in the butt that the Subversion developers just wave away with "look at svn log and see where things happened, then use the revision numbers!"

With our trailing Trunk tag, though, we can take the snapshot taken at the last merge-down point (in this case, branch creation) and diff it against the current HEAD of Trunk (yes, I realize the cranio-posterial reference here is not coincidental), and apply that to Branch 1.

Here's a sticky bit, though. Assuming all is well and there are no conflicts (or even if there are), we can't just do a straight svn commit. We'd leave the Branch 1 Trunk snapshot back in an inappropriate state, which would cause us to include older changes (which cannot be guaranteed to apply idempotently) in the next merge down. So we have to use a "special" commit. (I am aware of the euphemisms for "retarded" that are popping up in the context of my solution.) This commit-from-trunk-merge needs to do an svn commit, and, if successful, delete the old tag and recreate it from the HEAD of Trunk.

When it's time to merge Branch 1 up to Trunk, another diff is taken, pulling just the changes to take the most recent version of Trunk to Branch 1, version b1.4.

All of this relies on a bit of discipline, which complicated the script significantly. I had to use the first form of the svn merge command (svn merge svn+ssh://svn.example.com/repos/tags/Branch2-trunk-tag svn+ssh://svn.example.com/repos/tags/trunk branches/Branch2) for performance's sake, relying on the remote svnserve process. I had to check to make sure that the working copies were all in sync with the repository before attempting merges in either direction, although I suspect svn would have caught me with this anyway. (Developers should be merging down from Trunk frequently anyway, so I don't feel bad about this.) I have to make sure all the developers use the correct merge and commit statements to keep the repository intact, and I will probably have to resort to locking the repository during these operations, a thing I don't really look forward to doing.

I think I can support about 4-6 developers using this mechanism, more if they understand version control and branching. Beyond that, and I think I'm going to have to be very aggressive in breaking up projects into multiple modules and befouling the world with yet another SOA.

The underlying problem is that, really, you can apply the diff of any two sets of files to any other set of files, as long as the gnu diff can be applied to whatever target you have in mind. Sure, this is sweet and powerful in some fanciful situation, but for the common case of a branching project, it's like a gun with a hairtrigger and a secret firecracker set in the handle to give you a surprise.

1 Holy crap, this didn't die.

Loading mentions Retweet

I have finally come to the conclusion that Subversion is evil, and a general step backwards in software configuration management.

I had the same opinion prior to using it, but now, after a week of dorking with it, I can say it has lived up to its goal of being a better cvs than cvs. That can be compared to a goal of being a better Titanic than the Titanic.

I am very branch happy, and this is where I started itching with Subversion before I even dug into the manual. cvs is not renowned for being friendly with people who like branches, and I've spent a lot of time faking branches with tags in cvs.

I would prefer to use darcs, which is what I use at home, or bazaar-ng, but honestly, there just isn't the tools support for either of those that is available for Subversion, and training devs on the scm-du-jour is not billable activity. There's a slick IDEA plugin for Subversion, and along with maven 2's idea:idea plugin, you can have a version-controlled, integrated, happy project up in about ninety seconds. Not counting the time it takes IDEA to start up, read all the jar contents, and become usable, of course.

So I've been spending a lot of time trying to figure out why I can't grok branching on Subversion, and I really think it's just that I have this mental block. I don't require a lot, and I don't require anything that isn't available via Perforce, bzr, darcs, etc.

I've given up and accepted that I'll have to adhere to Subversion's fake branch and tag structure. I've created scripts to do the svn mkdir $PROJECT_NAME; svn mkdir $PROJECT_NAME/trunk; svn mkdir $PROJECT_NAME/tags; svn mkdir $PROJECT_NAME/branches; svn commit -m "created stupid base directory structure."

I've also created scripts that sort of do the merges from the trunk to a branch, and vice versa. I can't believe was a pain that is to do, because you really do have to think of them as independent file trees.

Imagine doing branching on a non-versioning filesystem using a weak diff program, and you're just about there. It required a little too much work to figure out "ok, I've branched at this revision, and I've made these changes, and I rebased/integrated/merged down at this point, then what changes do I need to make to push things back to trunk?" When the manual involves manual examination of log output to figure this out, you know it's a JV tool.

This is a very simplified workflow demonstrating a typical arrangement with two developers. With the series of events (assume time increases downward) illustrated here, everything is more or less ok until the owner of Branch 1 merges down the changes from t1.1, integrating the changes made by the owner of Branch 2. This merge should go fairly smoothly, but what's incredibly odd is Subversion's behavior after this.

If the owner of Branch 1 makes subsequent changes and then tries to merge b1.4 back up to the Trunk, there is no automated method to do this. All of the manuals seem to miss the fact that there are changes in b1.1 and b1.2 that do not exist in the Trunk, and advise that you manipulate the diffs manually, because there is no way to guarantee idempotent operations.

I foresee trying to use Subversion just as long as I have 3-5 developers to worry about, where we can create a lot of tiny branches, and commit them to the trunk. Then there will be a period of chaos when everyone works right on the trunk, and at that point, we'll be able to justify the licensing cost for a real tool, whether it be Perforce, Clearcase, or whatever.

All developers working on a single line of code is the dumbest idea in the entire universe, and I say that having been a Peugeot owner. What happens is that the less-disciplined developers hold back a month's worth of code (hopefully they're at least doing daily updates) and then check it all in at once at the end. If their drive blows up, or any of a number of data integrity issues arise, that's $50k+ down the drain (40 hours x 4 weeks x $200+/hr + $20k in salary, benefits, office space, etc.). Otherwise, they're making a lot of tiny checkins, and that's nice, but you're left with a tree in a non-coherent, incomplete, non-releasable state.

Sure, that feature your cave-dweller is working on may be a make-or-break feature for your client despite the fact that only a moron would be working in isolation for a month. However, that stuff happens, and if you need to demonstrate progress on short notice, it's far easier to build off the trunk and know you'll have a single functional unit than wonder which pieces are stubbed out, not working, or just plain spaghetti.

The best you can hope for in this situation is that developers will use their own version control for their branches. "Branch 1" will be in bzr on some guy's Windows box and "Branch 2" will be in darcs on some guy's Mac. They'll both be snapshots of the Trunk, and hopefully everything will just work out.

As with programming languages and development environments, I love that most people are happy working with stone tools, and if we want to live in the 21st century, we have to wear hair shirts.

Loading mentions Retweet

Others will cover the newsy bits better, but I rather enjoyed watching the fireworks from our lower deck, although a fair bit of the show was obstructed by a crane, I-80, and a couple buildings. More than made up for by spending the time with my parents and not "hundreds of thousands" of strangers who were there, according to the television news broadcast.

I took a bunch of shots with the exposure on my junk camera (SD400) lengthened somewhat, and the happy-smiley faces turned into something...less.

Had we deployed something like this over Afghanistan, Iraq, or Iran (oops, was I mixing past with future tense there?), I think things would have wrapped up much more quickly. Imagine seeing a sky of these instead of the boring green artillery that we saw 24 hours a day on CNN back in 1991.

In fact, if you look carefully at this picture, you'll see that, while city traffic was more or less oozing viscously along, and eastbound I-80 traffic was positively liquid, the poor (or lucky) people heading toward Oakland had the best seats in the house, and just sat still, terrified that we were under military attack.

Loading mentions Retweet

This had to have been the most painful web/db/php-based software upgrade ever.

$ cp drupal/sites/default/settings.php .
$ tar zxf drupal-4.7.0.tar.gz
$ cd drupal-4.7.0
$ cp -r * ../drupal
$ cp ../settings.php ../drupal/sites/default

And then, I had to hit update.php. Sheesh.

Loading mentions Retweet

We have one of those big industrial racks that are so popular right now that hides behind the spiral staircase between the first floor and the lower loft. Kat uses it for curing homemade soap (no Fight Club but good god it's awesome) and germinating seeds.

To keep the cats from eating all the plants, she planted some "kitty grass" seeds. It's not catnip (or we'd all be dead) but it's something that cats apparently like to eat, although they've avoided it so far.

This grass being the rather simple organism that it is, it just pushes the water upwards until it beads on the tip. I guess that's its way of saying,"Hey, we're full up here." It made a neat snapshot, and I wouldn't have thought anything of it until I zoomed in on it in iPhoto.

Not original or earth-shattering by any stretch, but I thought it was kind of cool what a cheap year-old pocket-sized digital camera can do.

After a little reverse psychology by a friend, by which I mean, he called morons who photograph stupid stuff and put it on their blogs, well, morons, I knew it had to be shared with the world.

Loading mentions Retweet

I have photographic evidence, thanks to the AP, that my wife has no common sense. Witness the picture above, where she (the only female human if you couldn't figure it out) went to the post office on tax day. Not to mail anything tax related, of course, but just because it was one of her errands. None of the things in her hands are payments, extension forms, returns, etc., since we already did that.

Oh, and she'd like the world to know that the camera lens and angle make her look "hippy", and that it's completely unrepresentative. While I can concur, such would not have occurred to me off the bat. Vive la difference.

I would, however, like to know what kind of idiots actually go to the post office and stand in line on tax day. Are they trying to find the slowest shipment method? Do they not know about "stamp machines" and "mailboxes"?

Edit: by "idiots" I meant "people with a single envelope that needs to go to the IRS" not "my wife". It took a while to update this with broken fingers.

Loading mentions Retweet

(Firetruck outside our front door last night)

Around 12:30am-1am today, the fire alarms went off. I dutifully woke up Kat (who claims to be a light sleeper but now I know she's lying), got dressed enough to go outside, grabbed ID, keys, phone, and cats, and headed down the stairs.

The stairs reeked of ozone and burning plastic the lower we went, and I was a little concerned that the fire would be coming up. We'd have to hop the roof to the neighboring building, which would be trivial from our lower deck, as the building next door tops off at exactly the same level.

We stood outside (in the rain, of course) for half an hour or so, and then the fire department, without actually going inside to inspect for any damage, disabled the alarm "for the night" and let us back in.

I had a suspicion, based on the smell, that it was the elevator motor, primarily because I didn't want it to be something that would actually involve fire, like a gas leak or burning plastic in someone's vacant apartment.

I stayed up for a few more hours, and at 4am, walked near the front door, where the smell was atrocious. I went into the hall and smelled the elevator shaft, and was almost knocked over. Another call to the FD was made, and the firepeople actually bothered to come into the building and investigate the cause of the smell. They identified it, disabled the power, and set up big fans to air out the stairwell, dispelling the bad smell to the roof.

Unfortunately, our bedroom juts out on the roof, and the door to the top deck is right next to the stairwell door through which the stink was being blown. As a result, the top two floors of our place were uninhabitable until about 4pm today, as we fought the battle using Febreeze, strategically placed fans and HEPA filters, and open windows and doors. We ended up sleeping on the couch for the night, which was...less than comfortable.

Anyway, we're not dead, but I have no faith that the SFFD would have prevented us from being dead if there had been an actual fire. It did give us a safe opportunity to plan for fire-related contingencies, such as surprising our neighbors on the building next door with a knock on their door at any time of night by two neighbors carrying a run kit and two cats.

Loading mentions Retweet

Apparently, you can't call it a "Ferrari" if it's just a bunch of plastic glued/stapled/taped to a Fiero. Who knew?

Loading mentions Retweet

I stumbled over a few of these in an archive (I find kit cars to be almost the funniest thing on earth), and thought I'd amuse myself with ready-made blogfodder:

Reply to: anon-76997776@craigslist.org
Date: 2005-06-04, 12:25PM PDT

ferrari body kit, ferrari tail lights, ferrari yellow, 5 spd 3.8 v6, holley throttlebody, funtional side scoops with ram forced air intake, Zeitner stage 5 performance tranny and clutch, only 25-30K on motor and drive train, Dual ocelot racing exhaust. needs some tlc on enterior, moon roof, NEW 17in Motegi wheels on Brand New Tires (with warranty). $1200 new. Just needs a little tlc. Gets Lots of stares and compliments. Make an offer or will trade for import of some sort, CRX, 2dr civics 91-up, 240sx and more! Or sell for 3k OBO with new wheels, $2300 without. Let me know!

Loading mentions Retweet

9:30 PM: Start Parallels and create a pre-configured instance for Windows XP, modifying RAM allotment to 512MB, relocating the data files to an external FireWire Drive, and changing the CDROM from an ISO file to the Mac's SuperDrive DL.

9:35 PM: Put Windows XP disk in drive, start VM.

9:46 PM: Windows XP installer says,"39 minutes left to install," as it copies files, probes hardware (probably especially easy with a virtual machine with constrained virtualised hardware), and tells me how much better life will be with XP. On my last install (on a PC), 39 became 23 which lasted for FOUR HOURS.

10:01 PM: Installer asks for configuration information.

10:02 PM: Installer finishes and reboots.

10:04 PM: I'm logged in and ready to go, looking at what I swear is Palouse country.

I installed the "Parallels Tools", (similar to the VMWare tools and the Virtual PC tools) which make the mousing smoother if nothing else. However, window movement is still a little flaky (I resized the window to 1200x800 or so, so it might be fine at 10x7 or another "natural" resolution.), but everything worked as it should. Surprisingly so, and so, so much faster than Virtual PC did on my G4, which is no surprise.

Again, much to my surprise, it used about 510M RSS and 1.25GB VSS to manage this, much less than I expected. Of course, I'm running IE right now and not Outlook, Office, Visio, and streaming video.

On the other hand, I thought I'd try a simple test tonight, and went to http://www.dslreports.com to try the speed tests, using the SF-based Megapath server. I expected there to be some cost to the virtual bridging in Parallels.

Captive Windows using IE and the latest Java 5 JRE plugin:

dslreports.com speed test result on 2006-04-07 01:42:14 EST:

4887 / 503

Your download speed : 4887 kbps or 610.9 KB/sec.

That is 197% better than an average user on pacbell.net



Your upload speed : 503 kbps or 62.9 KB/sec.

That is 38.5% better than an average user on pacbell.net

Host Mac OS X using Camino 1.0 and the craptacular Apple Java 5 JRE plugin:

dslreports.com speed test result on 2006-04-07 01:54:00 EST:

4896 / 499

Your download speed : 4896 kbps or 612 KB/sec.

That is 197% better than an average user on pacbell.net



Your upload speed : 499 kbps or 62.4 KB/sec.

That is 37.4% better than an average user on pacbell.net

Not much difference, and what difference there was, the Mac came out behind. So much for BSD networking! (Yes, that's a joke.)

I'll continue testing later this weekend with two of the PC games I keep my T40 around for: Scrabble and Age of Kings II: Age of Empires: Conquerors Expansion: Can we add more colons?

Regardless, at $49.95, I can't wait until they get out of Beta so I can buy the Intel Mac version. Based on what I've seen so far, I'd buy it in its present state.

(This is what is known as "foreshadowing". Be prepared for a raft of "Bloody hell this sucks!" posts in the near future.)

Edit: Wow, that was quick. Attempting to eject the Windows XP CD from inside the Windows VM caused a nice kernel panic in OS X. As my pappy used to say, when life gives you poop, make poop juice! So I used the forced reboot as an opportunity to install 10.4.6.

Oh, and I can't upgrade to SP2 because I don't have enough disk space (I went with the default disk size) and I can't find the resizing tool they talk about in the control panel.

Beta. Now I get it.

Loading mentions Retweet