kentcowgill.org/blog

So after some prompting, I added a few of my configuration files to subversion. In order to do that, though - I had to adjust them so they'd work no matter where they are.

For example, in my .vimrc file, I had to separate out the bits that makes my Mac happy from the bits that make the account on my server happy. This is what I seemed to settle on, but I'm not 100% sure it's the cleanest way to do it - I'm counting on the fact that my $HOME directory is particularly unique on my mac versus more unixy boxes:

The good news is that I've also installed Trac, adjusted the templates a bit to match the rest of my look and feel, and the end result can be viewed in the dotfiles section of my site.

Enjoy browsing around. The rest of my .vimrc is nicely loaded into Trac.

I'm working on making the rest of my code presentable, so that'll show up soon enough.

I don't mean to make this the "Andy Lester" week, but the company I work for is in technical debt -- there's no better way to put it.

For a little introduction on the concept of technical debt, there's a nice wiki page. But what brings it home for me are the slides from Andy's infamous technical debt, which are available on his website.

So what am I griping about?

Version control.

Love it.

Hate it.

Gotta have it.

Unfortunately, it's a big undertaking.

What we currently have in place is a script that does:

It even has enough brains to accept multiple files as arguments, even if they're in separate directories, and create the backup in a given files' subdirectory. While this (kind of) works, it's a pain for "rolling back", which I just had to do due to technical problems at our other office out of state. Especially painful when there had been changes to files that haven't made it to production, but the developer (me, in this case) is blissfully unaware of said changes, so it's not clear which version to restore.

Ugh!

Similar frustration for trying to re-restore the changes for eventual re-promotion.

But moving to a real^™ version control system is a chore. Why? Because there are 5-6 years worth of these archive files that would be nice to have as version history. Altogether, there are about 99,300 files total. And the perl program I wrote to import them into our version control system³ takes an average of about 3 seconds per file⁴. My math tells me that's about 3.5 days.

³ Perforce seems to be what the company has elected to use, even though the few times I've tried it, I've hated it. Nowhere as intuitive for me to use as more reasonable (and by the way, free) version control systems such as subversion.

⁴ Pitifully slow. But since the Perforce server is a bit far topologically, speed issues are to be somewhat expected.