Source Code Repository: The Commit Paradox

I shot myself in the foot today, figuratively speaking of course, while struggling with this little subtle dilemma surrounding the rules of code commitment (aka check-in):

1. To make effective use of a version control system, you should commit your changes often, even if it means committing partially completed features.
   
2. As a responsible developer, you should not allow your commit to break the nightly build and regression tests.
   

I had a piece of enhancement work this morning that I had just finished coding for, but hadn't adequately been tested so I didn't want to commit them to the repository just yet (trying to follow rule #2: don't break the build).

Just then, I realized that there's code duplication in a couple of places. So I decided to do some refactoring. An hour later, a credit of my stunning optimization skills, the code had been nicely refactored. The problem was: the feature enhancement no longer worked! Oops! I must have cut out some vital piece of logic somewhere. The original spaghetti code (that used to work) is now gone--eaten by the refactoring monster.

So in failing to follow rule #1, that set me back by about half a day.

But how can you follow two seemingly paradoxical rules such as ones above? On the one hand, you'd want to commit your changes as often as possible, and not wait until you've fully implemented the feature before committing. On the other hand, you wouldn't want your partial commits to break the automated build and regression tests.

Well, you might say that I should have made a back up of my changes before I start refactoring. Ah hah, but what's the point of a revision control system if you have to keep backups of your changes on the side?

I think the correct solution to this "paradox" would have been to use branching: create a new developmental branch for your enhancement work, even if it was a relatively small enhancement. This would have given me my own sandbox to play with and make partial commits to my heart's content, without breaking the nightly build (because the build would have continued to work on the MAIN branch). And then when I'm satisfied with my implementation, I'd merge the latest changes back into the MAIN branch.

Who needs GoToMyPC ;-)

GoToMyPC lets you access your PC desktop remotely from a web browser, for a fee, of course.

I think here's the next best thing: SSH + Windows XP Remote Desktop Connection. You use your SSH client connection to create a secure tunnel to your Remote Desktop PC. Granted, it's not the same as accessing your desktop through a browser, but...

If you're using Windows XP at home and you have an SSH server running on your home network, chances are you already know how to do this. Go and read more Dilbert--the rest of this article may not apply to you.

If you don't have an SSH server, and want to, install RedHat Fedora.

By default Remote Desktop Sharing is disabled on XP. You'll need to turn it on via the My Computer properties dialog.



In order to set up your tunnel, first, you'll need to download PuTTY, a very well-known SSH client created by Simon Tatham. If you're not familiar with this tool, here's the User Guide.

To create an SSH tunnel through PuTTY is quite simple. From the Tunnels Panel for your connection, add the following mapping:

• Source Port: 127.0.0.2:3389
  
• Destination: <Your RDP computer's IP address>:3389
  e.g. 192.168.2.100:3389
  
• Type: Remote
  

Now, after you've established the SSH session with your server, you should be able to start up your Remote Desktop Connection client and connect to your remote desktop by entering the 127.0.0.2[:3389] in the Destination field (the part in the square brackets are optional). The Remote Desktop Connection client is found on your Start>Program>Accessories>Communications menu, if installed. If you don't have it installed already, you can download it here

For convenience, I usually put a shortcut on my Desktop, pointing to <Path_To_PuTTY_Program_Folder>\plink.exe -load <My SSH Tunnel Session Name> -l <login name>. This allows me to establish the tunnel with one single click. All I need to do after that would be to type in my password, when prompted.




So why 127.0.0.2 instead of localchost [127.0.0.1]? Well, if you're using Windows XP on your local PC and you try to connect your Remote Desktop Client to localhost, you'd get a message by the application saying "I can't connect to myself" (I'm paraphrasing). The 127.0.0.2 IP address tricks the app into thinking that it's actually connecting to a remote computer instead of localhost.

Some of you nerds out there might wonder: why hassle with the SSH tunnel? Why not just connect to RDP directly? Well, I'm of a suspicious mind, and for some strange reason, I feel a little more secure when connecting through a 1024-bit DSA encrypted channel.

You can probably see that SSH tunnelling approach is not only limited to RDP, but can be used to create a secure tunnel into virtually any TCP service on the remote network: NetMeeting, VNC, Exchange Server.

I now have my mind set on my next toy: a wifi PDA running Windows Mobile. This way I can access my office desktop PC everywhere I go.