Neat!

One year in 40 seconds from Eirik Solheim on Vimeo.

Subversion revision history, Perforce style

I don't have a ton of confidence in Subversion, and am fairly comfortable with Perforce, so when Subversion doesn't obviously do something I know how to do in Perforce, I tend to throw my hands up in the air and say, "See? Subversion sucks!"

This, I'm coming to believe, is a bad habit. Case in point: change history - Perforce vs. Subversion. In Perforce, you do the following (of course, there are flags to get more or less information):

p4 changes (path)
p4 describe (change number)

In Subversion, you get the changes this way:

svn log (path)

That's fine, but now how do you get information about what changed? Cue throwing my hands up and cursing the tool. "How can I make log tell me about what changed," I'd think. But, as is often the case (and the sooner I realize this, the better for everyone), I'm not thinking about the problem correctly. Perforce requires you use two different commands to get the information I require. Why wouldn't Subversion? The only wrinkle is that Subversion doesn't appear to have a dedicated utility for "describing" a change. Rather, you use the diff utility thus:

svn diff -c(change number) (path)

or, to find out all of the changes committed at a certain revision number

svn diff -c(change number)

Please, make him go away.

Zombie says what?

Your technology might suck, if...

... you think it's appropriate to make the cover for your book about the technology involve confused-looking aliens with their first alchemical set they just got for alien Christmas.

Windows 7: The Mojave Experiment for Reals?

Recently, Microsoft launched a "viral" (what the hell does viral mean in this context?) marketing campaign entitled "The Mojave Experiment". The campaign is a series of videos in which people are shown Vista, but are told they are looking at a new Microsoft operating system codenamed Mojave. The people react positively to what they are shown, and then are surprised to learn that the OS they are looking like is actually Folger's Crystals.



It's an OS that's rich enough to be served in America's finest coffee houses!

So, I thought that marketing campaign was a little lame, and not really worth noting. Except soon after it appeared, I heard that a beta of Windows 7 may be available at PDC this year. It took Microsoft over 5 years to produce Vista, so I have to wonder - is Windows 7 really just the Mojave Experiment?

Schneier on Security : The Pentagon's World of Warcraft Movie-Plot Threat

Schneier comments on a salon article about a the use of World of Warcraft as a possible terrorist communication channel (emphasis added):

I don't know why he thinks that the terrorists will use World of Warcraft and not some other online world. Or Facebook. Or Usenet. Or a chat room. Or e-mail. Or the telephone. I don't even know why the particular form of communication is in any way important.

I have an idea why. The analyst is saying the opposite of "... not some other online world. Or Facebook. Or Usenet..." On the contrary: "revealing" this threat "reveals" the others, and for a purpose.

Government agencies aren't interested so much in stopping terrorists as improving their surveillance capabilities. Making a case that there are many communication channels (don't forget the nefarious NickelAds! Evil!) argues for initiatives like the IAO. An agency capable of watching all communication channels at once becomes an extremely powerful tool, and even an extremely powerful entity in its own right. It seems to me that the threat of "asymmetric warfare" is little more than a ruse for grabbing power.

We've always been at war with Eastasia.

MacVim

Google Code provides a nice native vim and gvim 7.2 port for OS X. Winnar. Thanks to Mr. Met for the tip!

Branches and Merging with Subversion

I found other posts elsewhere mystifying. None of them had a very good technical explanation for what Subversion was doing in the background, so the very best posts for me just had step by step instructions. You know... for monkeys.

So... here's my cookie-cutter, "joo can doo eet too" solution for dealing with branches and merges to and from a Subversion trunk repository.

1) Every day, I merged trunk -> branch and resolved conflicts. This kept shit from getting too far out of whack. I kept a log of what happened in case I needed it, and I tagged every commit from this procedure with the revision I merged from and to. For example (NOTE: I'm in a directory with the branch version of the code):

...
6/19 > svn merge -r 4130:4152 svn+ssh://svn.billy.net/data/svn/jooky/trunk
6/20 > svn merge -r 4152:4164 svn+ssh://svn.billy.net/data/svn/jooky/trunk
6/23 > svn merge -r 4164:4199 svn+ssh://svn.billy.net/data/svn/jooky/trunk
...
6/30 > svn merge -r 4368:4376 svn+ssh://svn.billy.net/data/svn/jooky/trunk

2) Ok, so, on the day of the big merge back you tell everyone to quit committing to either trunk or branch until the process is complete. I know, a revision control system should support locking. AFAIK, Subversion doesn't, so you just have to treat your fellow developers like adults and trust that they will follow your edict. Maybe tell them that whoever thwarts you by checking in has to do the merge for you :)

6/30 > svn merge -r 4368:4376 svn+ssh://svn.billy.net/data/svn/jooky/trunk

3) If that tests clean, here's the magic part: go to a directory that contains the trunk version of your code, and merge in this directory using this bizarre ordering:

> svn merge svn+ssh://svn.billy.net/data/svn/jooky/trunk svn+ssh://svn.billy.net/data/svn/jooky/branches/dbrb_4043

That's right: go to a directory with a trunk version of your code, and tell svn to merge trunk to branch (well, that's how *I* read that notation anyway. YMMV). Check it out! I have no freaking idea what Subversion is thinking here, but I can tell you from experience that this process works. ONLY the differences you want are carried from branch back to trunk.

[ Update ]

One thing that's crucial to this thing working right is keeping notes. Externally or using comments, note the revisions you're using.

Regarding the notes, I've seen a pretty common mistake using this technique that I think I need to make mention of. Don't ever use "HEAD" for any of these operations. You don't know what head is when you do this operation, and you will likely forget to make a note of it when you add your comment. This can cause gaps in your merge. Gaps are bad.