SCM workflow in TextMate

I’m loving coding in TextMate - it makes ruby much more fun. And python, too.

It integrates really well with heaps of other tools, including my diffing app of choice (Changes.app), and my preferred DVCS (Mercurial).

It even has its own Commit pane that appears when you choose to commit. There is one problem with it, however. Invariably I have made a change to a file and can’t remember exactly what it was. You can’t view the changes using the Mercurial bundle and Changes, and leave that window open while you commit. So, I end up having a terminal window open that I type hg chdiff into.

Instead, we should be able to quickly see the changes made to the working copy. Perhaps using a button like below:

Of course, that’s just a mockup (although it is done in IB) - the button is not connected up to anything. I have no idea how to reverse engineer the Commit.app to do this. But it would be cool.

Update: It appears all you have to do is tell the CommitWindow.app tool that you want to use --diff-cmd "hg,diff", and it is all done.

HOWTO: TortoiseSVN with lofty.

You need two items of software, TortoiseSVN and Putty. Make sure you get the Putty that has all of the extra tools, you’ll need puttygen at the very least.

Once you have installed Putty, open up the main putty.exe program. The installer put a shortcut on my desktop, yours may not have:

putty_exe.png

In the window that appears, enter lofty.infoeng.flinders.edu.au into the Host Name box:

putty_session.png

Then, enter lofty into the Saved Sessions box, and click Save. This will save you a little bit of typing later on.

Now, select the Data item from the left tree-view (you may need to expand Connection first). Enter your Flinders CSEM/InfoEng password into the indicated box.

putty_Connection_Data.png

Click back into the Session tab, and click Save again. Now click Open.

A new window will appear, which will ask you for your InfoEng password. You’ll need to enter it just this one time.

lofty_ssh.png

What we need to do is create a private/public key pair. One of these will live on lofty, the other on your local computer.

Before we do that, create the correct location to store this on lofty:

mkdir .ssh

Note that there is a dot before the ssh!

Now issue the command:

ssh-keygen -b 1024 -t rsa

Use the default location: ~/.ssh/id_rsa

Use an empty passphrase, and you’ll need to press enter twice. It then saves the file into this location, and creates a public key as well.

Enter the .ssh directory, and type in the following command. (Even if you already have keys in the file it copies them to, it will still be safe!):

cat id_rsa.pub >> authorized_keys

This copies the public key into the authorized_keys file, appending it to the file if it already exists.

We now need to get the private key onto your home machine. The easiest way is to type in:

cat id_rsa

and copy and paste the text into a new Text Document. Rename this to something sensible (id_rsa again is a good choice). Don’t ever let anyone else access this file, as if they do, they can get into your InfoEng account!

Now, run puttygen.exe. Click on Load, and select the file you just created in Notepad. You may need to turn on “All Files” in the file chooser. You’ll now need to save the private key. It’s a good idea to use the same filename, but with the ppk extension.

Now run another instance of putty.exe.

Click on the lofty Saved Session, and press Load. Then choose the SSH/Auth option, as shown.

putty_SSH_Auth.png

Use the Browse… button to select your keyfile. (The one with a .ppk extension, not the one you created first).

Before you click Open, go back to the Session page and click Save again. Otherwise your selection of the keyfile will not be saved next time you try to connect (but it will work this time).

Finally, click Open to test the connection. You should log in without having to enter your password.

That’s all of the Putty stuff we need to do. You can’t uninstall it, and it’s worth keeping around in case you need to SSH into the Uni machines again. When you do, it’s almost the same as opening a Command Shell on the Solaris machines, so you can do most of your work from home.

If you haven’t, install TortoiseSVN now.

Go to the directory that you want to keep your local copy of the SVN repository in. Right-click and select SVN Checkout… from the menu.

SVN_Checkout_Menu.png

The only things you’ll need to change are the URL, and possibly the last component of the Checkout directory. It’s currently called SVN, but you can call this last bit whatever you want.

Checkout_Window.png

Press OK. It will, in a fairly short amount of time, get all of the data.

The contents of the directory you checked out now have Badges, showing if they are up-to-date, Modified, or so on. I’ve created a Sandbox directory for you to play around in, but the good thing about SVN and other systems is that you can’t really break anything. Someone can always revert any changes you have made if you break a file, even if you accidentally delete it. It’s obviously better if you don’t but don’t stress if you do.

Badge_Icons.png

You’ll want to play around to see how to add files to the repository, and commit any changes you do make. Please make sure you Commit changes regularly, and Update often too. You may find that you have to Merge changes if two of us have modified a file at around the same time - there is a program called TortoiseMerge that you can use to do this. I’d really encourage you to play around and do this (you can even checkout two versions of the repository to your hard disk and make changes to the same file in each one, and they try to commit, just to see how it works).

Fighting with ssh.

It’s still relatively unusual for me to have to work on a system that I don’t have superuser status on - at home I am the administrator of all of the machines, and at work I have sudo privs on both the development and production servers.

At Uni, however, I have to play by some other dude’s rules.

And, that means sometimes not having software installed that I need.

Take mercurial, for instance. I use this as my exclusive RCS, because it is simple to set up a repo, easy to clone, plays nice with OS X, and with Trac. It’s extensible, and easy to merge changes from clones.

But it isn’t installed as standard, or even at all on the Solaris machines at Uni. SVN is, but I’m not about to go through the whole rigamarole of setting up an svn server again. It just doesn’t do anything for me that mercurial doesn’t but it’s more setup work.

And I create new repos all of the time. I have one for each of my topics, and every time I start a new project, I create a new repository. It’s just that simple: hg init.

So, I tried installing it as a general user. I have it so that it works to some extent: I have the ability to change my environment variables, so I can add ~/bin to my path, stick all of the hg files in there, and then the mercurial/ directory into ~/.python, which I then make my PYTHONPATH.

Then, I can happily use hg while ssh’d in (or logged in to one of the SparcStation machines).

But, I can’t use the remote access.

See, ssh <machine> hg <command> will not work unless a) hg is in the system path, and b) mercurial is in the system python directory. You can fudge the first part (by explicitly telling the local hg where to look for the remote hg) but then I can’t figure out how to tell it where to load the python classes from.

So, my solution is this: mount the folder using sshd (or in my case, ExpanDrive). Then clone the repository from the local machine. You can then happily work away on either machine, but to push/pull you need to have the folder mounted.

Bit of a bummer. I’ve asked for mercurial to be installed, but we’ll see if that happens or not…

Mercurial and Trac

I’m enamoured with Mercurial for all of my version control needs. I’d like Versions to work with it, but the response I got from the developer suggests it never will. “UI of Versions is designed completely around the concept of centralized version control “ I can see that the same type of interface would work quite well with Mercurial, or another DVCS, without too many hassles.

Still, even just with the CLI, I’m coping.

A couple of days ago I started playing with Trac for bug tracking. I had used Bugzilla (not for my own projects, but I use it at work), and it doesn’t work properly with Mercurial. The good news is that Trac does, almost out of the box.

The trac-post-commit-hook works fine, and allows me to have a repository linked in with my trac store, and when changes are checked in that have “fixes ticket:X”, it automatically updates the trac for that ticket. It’s a bit of a repetitive process to set it up (you have to manually edit both the repo/.hg/hgrc file, and the trac/trac.ini file to add support for each other, but it’s easy enough to do).

The only annoyance is that the username isn’t quite the same in both - so changes made in Trac have the username matt, whilst those made in mercurial have the default username there - which includes my full name and my email address.