I’ve already alluded to the fact that I love working on the console and in Windows, PowerShell is my console of choice. I get to throw all sort of things through it’s object based pipeline and play with them in fun and exciting ways.

I also have added to my path a large number of the GnuWin32 tools which are sometimes better at dealing with raw text like sed and occasionally grep instead of PowerShell’s Select-String. By having these utilities in my path I can better deal with being stuck in pure cmd.exe.

Anyway, one of my favourite utilities is Clip.exe. It comes out of the box in Windows 7 and presumably Windows Vista. I rolled my own for Windows XP although I believe that it may be available as part of a resource kit. In case it isn’t immediately obvious, what Clip.exe does is takes whatever is fed to Standard Input and saves it to the clipboard. Very useful indeed.

The clipboard is a great place for storing some data temporarily and I quite frequently find that I want to process it in various ways. I have a bunch of command line utilities that are perfect at this, but I have to save the contents to a file and pass that file to the utility. That sounds like busy work. Fortunately the GnuWin32 utilities and PowerShell both read from standard input. What I need is a tool that does the opposite of Clip.exe and writes the contents of the clipboard to standard input. What I need is Paste.exe. So I wrote it.

A simple compile…

$ csc .\Paste.cs

And after copying to my Utilities folder (which is in my path) I’m good to go.

An added bonus is that I handle files copied in Windows Explorer. These will be returned as a list of filenames.

By default I add an extra Environment.NewLine and the end of the content as it tends to make the whole thing neater in the console. If this is causing you hassles use the -r switch which will paste the contents in their raw form.

Paste in Action

I use paste to quickly view the clipboard contents:

$ paste

To strip formatting in the clipboard:

$ paste | clip

To filter clipboard contents:

$ paste | grep -i batman

As subjects of a PowerShell ForEach-Object:

$ paste | % { $_.Length }

If you find a common pattern, share it in the comments below.

Lately there has been some peculiar activity on the iTunes Australia store. Some of my favourite shows are becoming available only a day after being aired in either the USA or Britain. For the record, these shows are:

• Doctor Who
• Game of Thrones
• Mad Men

Both Game of Thrones and Mad Men have season passes available for just over $30. Oh, and that’s HD. A quick look and you are looking at about $50 for a Blu-Ray of season 2.

So suddenly we have an influx of shows that are timely and cheap (relatively speaking). Sure, they encumbered with the iTunes DRM and you have to use iTunes but I like to think that this is a good sign. It seems like Australia has become a test bed for online distribution.

Aside from the DRM (and the fact that you are restricted to Apple devices) there is one glaring omission, communication. The scheduling of when shows will be available is largely hidden until they are released. So right now I’m going on faith that the prompt deliveries will continue for the remainder of the season but obviously have no guarantee that they will. Even if some insight was given into when the next episode will be released that would be an excellent start.

The next issue is the overall experience. I have a setup with a Mac Mini and an Apple TV connected to my television. It’s a shame that I kind of need both. The Mac Mini has been delegated as the storage server and it can hold all my iTunes downloads. However the full screen experience is somewhat lacking and generally requires fiddling around with a trackpad and keyboard. The Apple TV on the other hand delivers a fantastic (if somewhat limited) full screen experience as you would expect. However there is no way to reliably cache your shows on it so as to avoid disturbances due to issues involved in communicating with Apple’s servers. The device itself has a substantial buffer, but to buffer an entire show generally involves starting it, hitting pause and waiting for it to download completely without looking at anything else in the meantime.

So this is where the Mac Mini comes into its own. I can open up iTunes and download the shows I have purchased and share them with my Apple TV through the Home Sharing feature. Unfortunately the Apple TV interface for Home Sharing isn’t as slick as the regular TV interface, but once you get going it doesn’t really matter. The Apple TV also serves as a great way to browse the iTunes store and purchasing items is really easy.

And with this ease comes a small snag. It appears (and has been confirmed by a support request with Apple) that when you purchase a season pass on an Apple TV you cannot set up iTunes to automatically download new episodes as they become available. You can still download these episodes manually though, so the limitation won’t stop you from downloading your purchase shows, but it does make it just a little bit harder.

The workaround of course is to perform the actual purchase via iTunes on the machine that you want to download the episodes to. So unfortunately for the moment the keyboard and trackpad attached to my Mac Mini are there to stay.

Fortunately iTunes does send an email when a new episode of a show you’ve subscribed to is released, so this acts as a prompt to kick off the manual download.

I love the command line. Very rarely do I ever not have a console window open. Consequently I tend to do all my source control activities from the command line. However I’m not a command line bigot. I know when the console has reached its limit and I have to resort to a more graphical tool. With Mercurial this hits hard when doing complicated diffs and of course the dreaded three way merge. Fortunately Mercurial has been configured out of the box to recognise my merge tool of choice so when Mercurial finds a conflict during a merge it can show me a GUI based tool that will help me get on with my work.

But what about the times when I want to review the changes that I’ve made? This is especially important when I’m about to push changes and inflict my work on other developers. It’s also a great opportunity to spot issues which may result in broken builds.

For small changes I still stick with the console and run:

$ hg diff

This gives me a fairly simple diff of my changes. I can make this even better by enabling the color extension which will spruce up my command line output by adding colour to a myriad of different commands, but importantly for this case, diff. By marking insertions in green and deletions in red I can get a very quick overview of the changes I have made. To enable this extension I just add the following to my mercurial.ini file.

1
2

[extensions]
color =

However a basic diff is somewhat limited. It generally won’t take the filetype into consideration and a small change to a big line can be difficult to spot. Fortunately there are a number of great diff tools out there. The one I use is Beyond Compare 3 (you’ll need the Professional version if you want its excellent three way merge feature). It isn’t free, but for a tool I use every day I feel that it has been worth it many times over.

These instructions should work with any diff tool capable of understanding command line parameters and able to compare two folders.

To integrate our graphical diff tool with Mercurial we’ll turn to another extension, Extdiff. This extension helps you use a graphical diff tool to compare two different changesets (or a changeset with the current work in progress). Importantly it also makes sure that if you make any changes to the working copy they will be propagated back when you are done. So if your diff tool is good at moving changes from one file to another and editing files in place you can very easily clean up your changes. Enabling the extension is straightforward.

1
2
3

[extensions]
color =
extdiff =

This has however only enabled the extdiff command in Mercurial. If we want to configure our diff tool of choice we have to make one final change.

1
2
3
4
5
6

[extensions]
color =
extdiff =

[extdiff]
cmd.vdiff = C:\Program Files (x86)\Beyond Compare 3\BCompare.exe

Here I’ve added the extdiff section and created a new command vdiff which will use Beyond Compare as my diff tool. So now to use Beyond Compare to view my changes I just need to run the following:

$ hg vdiff

I can create as many of these commands as I like if I want to enable different diff tools. It is also possible to parse arguments to the diff tool. For instructions check out the Extdiff documentation page on the Mercurial wiki.

I’m a huge fan of version control. I have fond memories of first learning Subversion and setting up a source control server. I also remember the pain involved every time I wanted to create a new repository. Sure, I had a good process and it wasn’t that bad, but it was still something. For a long time I really thought that nothing could be better. Then I was introduced to this:

$ hg init .

That one line changed my life forever. Pretty soon I had just about everything I was actively working on managed by source control. It truly was a golden age. At this time I was generally working inside my own repositories sheltered from the rest of the world. Even for a single user Mercurial came to my aid by protecting me from myself. Coupled with an awesome diff tool I felt unstoppable. I was able to better break down problems and experiment more knowing that I could easily get back to a known good state and easily examine exactly what I’d just changed.

Of course as these things go it was only a matter of time before I was able to really dive into a repository that was actively maintained by other users. Here I was finally able to see if Mercurial was worthy of all the hype that I had read having consumed plenty of documentation (and forgetting all the things I wasn’t using on a regular basis).

And I was generally happy. But one thing continued to niggle at me. The number of “Merge” commits seemed extremely unnecessary. So I looked into the rebase extension. Now I was able to graft my changes at the end of everyone else’s history. Most of my changes were fairly isolated and there were rarely any conflicts (and when there were easily resolved with a simple three way merge).

And so again, life was good. But as time moved on I became wary of all this rewriting of history. One instance of sending duplicate changesets to the ‘master’ repository will quickly identify how easy it is to do the wrong thing. Wasn’t Mercurial supposed to save me from all this? I lost faith and began to look elsewhere, learnt the ins and outs of Git and really came to like the light weight branching it offered. This seemed to be perfect for what I wanted. I could have feature branches on bits of work that I might do and then merge them into the trunk when I’m done. Suddenly the merges didn’t seem so bad as each served a specific purpose of bringing a feature to the main line.

So I looked into Mercurial branches. Branches in Mercurial aren’t as lightweight as in Git. And even when they are closed traces of them seem to last forever. That might be fine for some cases, but for the work I was doing I didn’t want to worry about coming up with unique names for my branches and have those choices persisted for all eternity.

So I went for a search to find how other Mercurial users tackle this apparent shortfall. The answer was to maintain multiple heads and to use bookmarks to manage each head.

When I was first learning about Mercurial I suppose I gave myself the impression that multiple heads were bad and whenever there was more than one head you need to merge. This is of course completely wrong.

Mercurial quite happily chugs along with multiple heads and indeed it is fairly fundamental to how it works. When it comes time to push your changes you might run into issues, but even here we can work around them.

How I use bookmarks to manage multiple heads

When you have multiple heads to work with it becomes evident fairly quickly that you will need to have a good way to switch between these heads. This is where bookmarks come into play. So let’s look at an example of how this works:

I’ve opened up my trusty console window and have updated my repository.

$ hg pull -u

I’ve used the -u switch here to update the repository at the same time as pulling the latest changes. I don’t have any bookmarks set yet so I’m going to create one now so that I can easily track the ‘tip’ from the ‘master’ repository. I’m going to call it ‘master’ because that’s easy to remember.

$ hg book master

I’ve shortened the bookmarks command to book because book is easier to type and still gets the point across without being too cryptic. Now I’m going to start working on a fairly major change. I want to be able to commit often as I know that I will get things into a partially working state frequently but don’t want to share my changes until I’m completely done. So I’ll create a new bookmark to keep track of these changes:

$ hg book batman

So now I have two bookmarks that both point to the same changeset. Importantly the active bookmark is batman because it’s the last bookmark I used. You can only have one active bookmark at a time. To see the bookmarks that I have I can just run the book command with no parameters.

$ hg book
 * batman               34:7f6c4f9e45fb
   master               34:7f6c4f9e45fb

Looks good. The * indicates which bookmark is currently active. Note that they both point to the same changeset. Now I’m going to make some changes and commit:

$ hg commit -m "Improved grapple."

Now if I look at my bookmarks I’ll see that batman has moved with my new changeset and master has stayed put.

$ hg book
 * batman               35:63a4549bc962
   master               34:7f6c4f9e45fb

This is generally the point where someone might interrupt me with an urgent change. This time I know it is a simple change and we need to get it into the master ASAP. I don’t want to risk my improved grapple though and this change is unrelated anyway so I’ll start back at the master bookmark.

$ hg update master
1 file updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg book robin
$ hg book
   batman               35:63a4549bc962
   master               34:7f6c4f9e45fb
 * robin                34:7f6c4f9e45fb

Now I can make my change and commit.

$ hg commit -m "Reduce brightness of Robin costume."
$ hg book
   batman               35:63a4549bc962
   master               34:7f6c4f9e45fb
 * robin                36:9832ab432fec

Now I can see that the robin bookmark has moved, the batman bookmark stays in place and the master bookmark still points to the last changeset I pulled from the master repository. At this point I technically have two heads.

$ hg heads .
changeset:   35:63a4549bc962
bookmark:    batman
user:        Rhys Parry <rhys@example.com>
date:        Wed Apr 3 20:40:12 2013 +1000
summary:     Improved grapple.

changeset:  36:9832ab432fec
bookmark:   robin
tag:        tip
user:       Rhys Parry <rhys@example.com>
date:       Wed Apr 3 20:52:19 2013 +1000
summary:    Reduce brightness of Robin costume.

Because we have bookmarks for these changesets we can quickly switch between them. Here you can also see that the robin changeset also is regarded as the tip of the repository. Because this change is urgent I want to push it to the master repository ASAP. So first I’ll check if there is anything new in the master repository.

$ hg in
comparing with B:\Batcave
searching for changes
changeset:   37: f33b6a00e172
tag:         tip
user:        Alfred Pennyworth <alfred@example.com>
date:        Wed Apr 3 20:38:19 2013 +1000
summary:     Improve delivery of hot cocoa.

Here we can see that there has been a change since I started working. If I want to push this change I’ll need to merge my changes. But first I’ll make updating as simple as possible.

$ hg update master
1 file updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg pull -u

This will pull in Alfred’s changes and leave us with three heads. Importantly when we used hg update master Mercurial knew we were switching to a bookmark so it set it as the active bookmark. When we pulled in Alfred’s changes the bookmark followed the update so now master is pointing where we were expecting it to.

$ hg book
   batman               35:63a4549bc962
 * master               37:f33b6a00e172
   robin                36:9832ab432fec

Now we just need to merge the robin branch into master and we’ll be in a position to start pushing our changes. Again, this is straightforward.

$ hg merge robin
$ hg commit -m "Merge Robin costume improvements."

This time I can easily come up with a merge message because I know that there is a common theme to what I am merging. The same would apply if I was merging one hundred changesets. I can also now think of the merge as a true change and not just a nasty side effect of my choice of version control system. Finally I am ready to push my changes to the master repository. Because I don’t want the changes from my batman bookmark going up I’ll take a bit more care and do the following:

$ hg push -r master

This will push the master bookmark and all its descendants (which now includes the robin changes as well but not the batman changes). If you want to preview what changesets you will be sending to the master repository you can always run the following command first:

$ hg out -r master

Sometimes you might forget to include the -r flag. If you do Mercurial will kindly refuse your push and none of your changes will be pushed. By default Mercurial isn’t keen on letting you push extra heads to other repositories.

With this in mind we can feel a little safer knowing that Mercurial will prevent us from inflicting our unfinished changes on others before their time. We can of course force these changes if we want:

$ hg push --force -B master -B batman backup

Here I’ve forced these extra heads to be pushed to my own backup repository so that if my machine fails all my changes, including the bookmarks (which are not pushed by default).

So that’s a peak at one of the ways I use Mercurial on a daily basis. I’m sure there are many improvements to the way I am currently working and I relish the opportunity to explore more of Mercurial’s functionality.

So it seems as though I forgot a couple of points in last night’s blog post (First Impressions of Google+).

I should be able to sort my circles

While you can create new circles there doesn’t appear to be any way to sort them. Unfortunately this means that my extreme circles (close friends and fringe) are right next to each other and that’s just not right. However the problem really becomes evident with the menu list of your streams. Only your first custom circle is shown in the list (when you have added more than two custom circles). These are also sorted alphabetically after the predefined circles, which is a little odd, but I can see why it might be the case.

Preliminary conclusion

I think that at least in my case, Google+ is more likely to displace Twitter than Facebook. That said I’m not overly active on Facebook, but I find using twitter is a great way to keep up to date with the people I actually care about and a little industry stuff as well. I think Google+ is well targeted for that particular purpose. Like Twitter though you only know who is actually listening, not how much they care about what you say.