Cleanup/delete all .svn folders

I recently needed to recursively delete all of the .svn folders in a directory because I was copying them into an existing working copy (and who knows what would happen if you mixed in .svn folders from a different branch?). The google helped me find this cmd.exe one-liner, and I’m simply reposting it here for reference:

FOR /F "tokens=*" %G IN ('DIR /B /AD /S *.svn*') DO RMDIR /S /Q "%G"

This is assuming you’re sitting at the root folder where you want to recurse from.

Tip: Kill TSVNCache.exe to speed up Visual Studio startup times

When Visual Studio 2005 took over 3 minutes to start up, I figured that was just the price to pay for using a feature-filled/bloated IDE. After all, our working copy has some 20,000 files, and I’m running ViEmu and Resharper add-ins. And I was willing to pay that price – I just had to “plan” my water/coffee breaks around when I wanted to start and stop Visual Studio.

Well, my boss decided to investigate, and eventually determined that the culprit was the TSVNCache.exe process. TortoiseSVN runs this program in the background to keep all of your nice icon overlays up to date. It’s no secret that this process is a memory and disk I/O hog. I had already upgraded to the newest version, which claimed to make performance improvements. One strategy is to limit the folders it watches. Another is to lower its priority. Even with these tweaks, it was still taking Visual Studio a long time to startup and exit.

Finally, we looked at the TortoiseSVN settings and saw that we could essentially disable TSVNCache.exe from running at all. This was under

TortoiseSVN > Settings > Icon Overlays > Status cache

There are two options that will kill TSVNCache:

1. Shell
2. None

I decided to go with “Shell” since it still gives you real-time status. The disadvantage is that status is not recursive, so folders containing modified files will not show the modified overlay.

The results after disabling TSVNCache.exe were astounding. It only takes a minute for Visual Studio and all of my add-ins to load, and less than 5 seconds for it to shutdown!

Making the Windows Command Prompt a little more humane

If you spend a lot of time in the Windows command prompt, here are some tweaks you can make so the experience is more pleasant.

Changing the appearance

The default font and color is rather plain. I like to change to a ClearType font so I get anti-aliasing, and then bump up the contrast with a throw-back monochrome theme. Under Properties | Font, Lucida Console is a good alternative. It’s probably your only alternative. If you’re feeling ambitious, you can add to this list of fonts.

I also increase my buffer size (so I can scroll back farther) and increase the window size (so I can see more).

(Properties | Layout, Screen Buffer Size > Height: 500, Window Size > Height: 50)

The default prompt puts your cursor on the same line as your current working directory. You can modify your prompt by changing the PROMPT environment variable. I set mine to [$p]$_$g so that my cursor is on the next line, and always on the left of my terminal. There’s more information on Hanselman’s blog, where I lifted much of this.

Tab completion should be on by default in Windows XP. But if it’s not enabled for some reason, please enable it. And, did you know cmd.exe has a command history dialog? Hit F7 to get a list of your recent commands:

I hope that makes your command prompt experience more enjoyable. The next thing I’d like to get in the habit of using more is pushd and popd…

Campfire tray notifier application

At work, we use Campfire for intra-office communication. It’s been a real boon for keeping everyone up to speed one what’s happening, especially since many of us are separated geographically. It’s also great because we can properly manage our attention–if I’m in the zone, I’ll choose to ignore campfire, and at a later time I can catch up on the logs.

When we were first starting off incorporating Campfire into our process, though, the challenge was the social problem of getting everyone to learn a new habit of checking in on the chat and be there. The value of business chat is in the participation. Some of us needed Campfire to behave a little more like a desktop app that could provide invasive notifications to remind us to visit the web page.

For Mac, there is Pyro, which you can hook into Growl. But, since we were all on PC’s, that wasn’t viable. So, I turned to AutoIt and wrote a script that watches for changes in the web page title and pops up a balloon notification when there’s a new message. Recently, I got an email from someone requesting this, so I’m posting it here.

Here is the AutoIt script:

Opt("WinTitleMatchMode", 2)
Opt("WinWaitDelay", 500)
$isBalloon = 0
$last_title = ""
Do
    $title = WinGetTitle("Campfire: ")
    If WinGetTitle("") == $title Then
        $last_title = $title
        ContinueLoop
    EndIf
    If StringInStr($title, "(") AND $title <> $last_title Then
        $last_title = $title
        $parts = StringSplit($title, " ", 1)
        If ($isBalloon = 0) Then
            $isBalloon = 1
            TrayTip("New Campfire message!", "There are unread messages in the " & $parts[3] & " chatroom.", 10)
        EndIf
    Else
        $isBalloon = 0
    EndIf
Until 0

After downloading and installing AutoIt, you’ll be able to run this script (paste this into a text file and give it a “au3″ extension). You can also turn it into an exe using Aut2Exe and drop a shortcut into your Windows Startup folder so it will be there on bootup.

This script only works for IE (6 & 7, I think) because of how the web page title is formatted. That was sufficient for our needs, but I don’t think it would be hard to modify. I haven’t had a chance to test this, but here’s the code.

Collaborating with Mercurial

Now that you’ve got Mercurial running on your local machine, what if you want to collaborate with someone else? The easiest way to do this is to run “hg serve”, which starts a local http server that allows others to browse your repository, view changelogs, clone your repository and pull your changes. This is deemed an “informal” method of sharing because it provides unauthenticated read-only access to your repository. You wouldn’t use this to share your code with the public, but it works great within company walls if you’re trying to work with a coworker on something.

Again, it’s very simple and you’ll have it running in less than a second. Inside your repository, do:

hg serve

By default, you won’t see any output. You can verify things are working by navigating to http://localhost:8000/.

Now that you’re sharing your repository, Charlie can point his browser to http://[your machine name]:8000/ and browse your changelogs, files, tags. If he wants to start making changes, then he would:

hg clone http://[your machine name]:8000/ destination_directory

This will print out some status messages about what it’s doing. Now Charlie has a repository one his machine that he can start working with. If I make subsequent changes, Charlie can pull them into his repository by doing:

hg pull http://[your machine name]:8000/

And vice versa, if Charlie commited some changes, he would run “hg serve” and I would pull from his computer.

This is merely an introduction to doing some lightweight collaboration. In this scheme, since the “hg serve” provides read-only access, we are using a “pull only” model. This may not be practical depending on your project, but again, this is a quick and easy way of sharing and collaborating on code.

Sparklines

My friend Erik sent me some biostatistical data that he has been tracking over past few weeks. I decided to see what it would look like as a sparkline. There are a bunch of libraries and web services to generate these things, and I tried to find the simplest one implemented in Python. I found Matthew Perry’s module, installed PIL, and I was good to go. (I made a slight change to spark.py to expose the background color of the image as a parameter so the graphic would match my current theme.)

More data to visualize: I’ve been recording my gas mileage information since November, 2006. We can also note that gas prices have been steadily climbing since then (low: $2.10, high: $4.26). The simplicity and attractiveness of these graphics make them particularly compelling. I can think of a few places where using sparklines would be useful…

Enso lives on

Days after I lamented about Enso’s death, Atul posted a progress report, providing an overview of what’s been going on since open-sourcing Enso. I did suspect (and hope) that Enso was was, in fact, not dead – I poked around the code repostitory and browsed the developer’s forums and saw some healthy activity. I was glad to finally hear some direction for where the project is going. Enso is very much alive:)

While looking through the discussions, I came across a nifty Enso interface demo by Andreas Schuderer implemented in JavaScript. It’s a great example of “Show, Don’t Tell”.

Using Mercurial as ad-hoc local version control

Let’s assume you’re working at a company using Perforce or Subversion as source control, and you’re tasked to fix a bug on the main branch of development. You’d prefer not to commit anything into the repository that breaks, lest the build master (who may be yourself) get on your case and you’re additionally tasked to buy donuts for the group.

If the bug/change you’re trying to make is anything beyond the most trivial task, it would be great to have your sources under version control so you have the freedom to try things and backtrack—you know, one of the basic ideas behind version control. So, now you’re stuck. There’s too much overhead to create a whole new branch just for this one fix. Do you resort to renaming files and folders and moving back and forth on your editor’s undo buffer? C’mon now, behave.

When the tools aren’t working for you, find a new tool! Enter Mercurial. I won’t get into the interminable debate between Mercurial and Git and other DVCS’s. Suffice it to say that they are all the NBT, and distributed VCS are a superset of centralized ones. I’ve chosen Mercurial for pragmatic reasons: 1) works well on Windows and 2) is implemented primarily in Python.

The basic idea is, you can use Mercurial on top of your current, centralized version control system. This way, you get all of your local sources under version control independent of what the rest of your company uses. It’s a simple idea, but it frees you from worrying about how to manage changes you’re making in your local area. Another situation I frequently find this useful in is when I’m writing a one-off script that I’m not sure if I want to commit to the repository. But, the script is complex enough that I’ll need to iterate a few times. Wouldn’t it be great to have it under version control? Here’s how:

Install Mercurial

I’m on Windows, so I just go for the Windows binary package where Python and everything is all wrapped up for you. You can also install it with cygwin, if that’s your bag. Make sure C:\Mercurial (or wherever you installed it) is in your path.

Now, you’re good to go. The executable name is “hg” (get it?) and if you type that without any arguments at command prompt, you will see a list of basic commands. All the concepts of version control that you’re familiar with are all there. Let’s walk through an example of putting your sources under version control and making some changes.

Create a new repository

The first thing you’ll do is create a new repository from your current sources. Let’s say you’re working on on a project in C:\projects\GoogleKiller. Navigate to that directory, and type:

> hg init

That command should return silently. It generated a .hg folder in that directory where the metadata is stored. You’ve just created a repository. You can now do:

> hg status
? GoogleKiller.py
? GoogleKillerTests.py
? README.TXT

This tells you that mercurial sees three files, but none of them are tracked. To start tracking them, simply:

> hg add
adding GoogleKiller.py
adding GoogleKillerTests.py
adding README.TXT

Without specifying any files to “hg add”, you’ve added all the files in the directory. Now, the last step to getting these sources in the repository is:

hg commit -m "Initial checkin!"

The -m argument is the log message for the checkin. You can track the history of commits with the log command:

> hg log
changeset:   0:8c047c4da9a4
tag:         tip
user:        bentsai@example.com
date:        Fri May 30 17:32:17 2008 -0400
summary:     Initial checkin!

Now you’re ready to roll with local version control:)

Start coding

The commandline help for mercurial is pretty good. The basic commands you’ll care about are:

• hg status (to see what files have been modified)
• hg diff (which prints out a unified diff of what’s changed)
• hg revert (for backing out of changes)

To get more details on these commands, just type “hg help <command>”. There are other tweaks you can make to the usage (the documentation is good), but that’s the general idea. Now you’re free to get on with coding!

The process for getting up and running is pretty low on friction, which is why I like it. This doesn’t even begin to touch the real boon of DVCS’s—actually collaborating with others. But this technique takes advantage of Mercurial’s speed, easy-of-use, and unobtrusiveness for a rapid solution to a fairly common problem.

Update (June 1, 2008): I should note that using Mercurial for version control isn’t limited to code. Any situation you’re keen on rolling back changes, this could work. Before I found out about Mercurial, I thought about using Subversion for such a purpose. But the pain was setting up a server – with Mercurial, there is no centralized server to setup. The only thing Mercurial does is add an “.hg” folder in the root. Once you have it installed on your computer, you’ve got localized Time Machine-like powers at your fingertips.

Update (June 2, 2008): Here’s someone who’s using Mercurial specifically with Perforce and described his workflow more extensively than I have.

That looks about right

[C:\Documents and Settings\btsai]
>history | awk ‘{print $2}’ | sort | uniq -c | sort -rn | head
‘history’ is not recognized as an internal or external command,
operable program or batch file.

Enso dead, back to launchy?

It sounds like from Jono’s posting that Enso is effectively dead, in the sense that no one is working on it full-time, let alone getting paid for it. The main changes I’ve seen on the code front look related to getting Enso to work on Mac, which is pretty ironic because Enso was one of the few pieces of software that made my PC borderline likeable. I was drawn to Humanized’s ethos – a slick combination of Python, UI, and a vision for how the computing world could be different. Unfortunately, their business model wasn’t forward-thinking enough. I believed in them – after all, they made a big splash on release with Mossberg giving a good review, and the founder is the son of the father of the Mac – and I even sent some money their way. I was hoping Enso would develop into a beautiful layer on top of Windows, hiding all the warts and bringing some coherency to the whole experience.

Hopefully, their vision finds its way into the real world through Mozilla. Seems like an excellent deal for them to be able to reach millions of users. For me, should I just go back to Launchy (which got a nice rewrite using Qt in 2.0, btw), or keep using my purchased copy of Enso that I’m adapted to. Or should I stop writing about productivity software and start producing software?:)