In the past 2 months I've had the opportunity to use two popular web hosting platforms: Heroku and AppHarbor. I used Heroku to host the blog I wrote using Ruby, Sinatra, and Padrino. AppHarbor was used to host a ASP.Net MVC3 application with SQL Server. I'm writing my experience here.

Heroku

The experience in deploying to both Heroku and Appharbor was great overall. Without Heroku I could have potentially faced hours of reading through help docs and googling error messages, and it's likely I would've given up. Heroku gave me the ability to get my app deployed, and for a novice *nix user that was a huge value. However, it didn't take me long to remember a familiar quote "Automatic just means you can't fix it when it breaks". So far it hasn't broke, so it hasn't been a problem.

Database development and management is a little awkward. I used Sqlite for development, and used the tools in ActiveRecord to connect to a Postgresql instance on Heroku's servers. In my trivial blog application this worked without incident. However, I have never used Postgresql and don't have any motivation to. If I would have needed to leverage some more advanced RDBMS capabilities, I would have preferred to use something I'm more familiar with: SQL Server or MySql.

As a Mercurial user, the deployment experience was a little more arduous than if I had been using Git. The workaround is to use an extension called Hg-Git which acts as a bridge. Hg-Git took longer to configure and setup than I was willing to spend on it(2 minutes?) so I abandoned it. Instead I just created a git repository in my application and committed to it only when I needed to deploy. My .gitignore filtered all the Hg related files, and my .hgignore filtered Git related files. Messy.

The interface for deploying to Heroku is done through a ruby gem. Setting up an account and new application has very few interaction points. I would have preferred to interact with a GUI than reading through help docs to find the right command.

This blog is hosted for free on Heroku.

AppHarbor

Most of my career has been spent building and deploying Microsoft ASP.Net based solutions to IIS. I've fought those dragons enough times that I know what to expect and how to get around the common error messages. Even so, I found AppHarbor to be a breeze compared to a manual deployment.

I use Mercurial almost exclusively for source control along with Bitbucket for free private repository hosting. I was extremely impressed with the integration between Bitbucket and AppHarbor. All it takes is "hg push" for my app to be copied to my shared Bitbucket repository which triggers a copy to AppHarbor which triggers a build and deploy. If you're a Git user, it is also natively supported.

AppHarbor supports MySql and SQL Server. This made database development simple since I can use SQL Server Management Studio to connect and manage my database hosted at AppHarbor. This also means I can use all the tools I know and love for copying schema and/or data.

Setting up a new app is all very simple and straightforward and done through the website.

My small app is hosted for free on AppHarbor.

Summary

I think it's awesome that we have so many great options for development, deployment, and hosting. I've never wanted to spend time figuring out deployment, hosting, or source control issues. These tools get me very close to not having to think about them at all.

Heroku caused a lot of fuss when it was made available for the ruby web world, but AppHarbor is a solid answer that stands up to and even exceeds Heroku's usability. I'm sure each will continue to grow and get even better.

I've found that closing named branches in Mercurial has been a good practice. Not only is an explicit statement that the feature is wrapped up, it also removes the head (a changeset with no children) from the repository.

You also get some nice visual cues from the TortoiseHG Workbench UI:

Steps to close the branch and merge it back to default:

$ hg up feature-branch-name
$ hg ci -m 'Closed branch feature-branch-name' --close-branch
$ hg up default
$ hg merge feature-branch-name
$ hg ci -m merge

My team recently upgraded the version of Mercurial we are using to 1.8. The biggest draw for me was the completely revamped TortoiseHg workbench.

Along with Mercurial we are using the shared repository hosting application that ships with the product. When we pushed a new repository created with Mercurial 1.8 and pushed to the server that had 1.5 installed we saw an error when viewing the page generated by the hgwebdir.cgi script:

wsgicgi.launch(application) File "mercurial\hgweb\wsgicgi.pyc", line 72, in launch File 
"mercurial\util.pyc", line 231, in increasingchunks 


c File 
"mercurial\templater.pyc", line 60, in process File "mercurial\templater.pyc", 
line 79, in _format File "mercurial\hgweb\hgwebdir_mod.pyc", line 238, in 
entries File "mercurial\hg.pyc", line 82, in repository File "mercurial\localrepo.pyc", 
line 2220, in instance File "mercurial\localrepo.pyc", line 74, in __init__ mercurial.
error.RepoError: requirement 'dotencode' not supported 

It's been a year since I setup the HG server on my IIS 6 Windows server 2003 box, and I remember it being a little touchy. At that time I was using this walkthrough. There may be/probably is a better walkthrough available by this time. Due to my travails in setting up the server initially I thought upgrading the server would be a pain. Thankfully not so.

Upgrade Steps

First thing I'd do is back up the virtual directory for the current setup. For me that was C:\Inetpub\hgcgi\.

Now delete the mercurial folder (highlighted above).
Next, find your installation path for Mercurial 1.8. Mine was in C:\Program Files\Mercurial. (Before I installed 1.8 I uninstalled the earlier version.) Inside the Mercurial directory unzip the library.zip file.

Inside the library folder find the mercurial folder:

Now just copy the mercurial folder from the installation of 1.8 into your virtual directory underneath the "hgcgi" directory.

That is as simple as it was for me to upgrade.

It's inevitable at some point during your development using a CVS and branching that you'll come to a point where you need to get a snapshot of changes between two branches.  Here is trick I picked up along the way that might be useful to other Mercurial users.

Visualizing Change with WinMerge

Even though I like to stay at the command line to speed up repetitive tasks, there are some things that are just better with a GUI.  WinMerge is free, and integrates perfectly with my Mercurial workflow. 

Directory comparisons show only directories/files that are different in your project tree:

Drilling down through the directories and double-clicking a file shows the comparison:

Launching a WinMerge Directory Diff From the Command Line Using Mercurial

To get to the goodies in WinMerge without a lot of fuss requires editing Mercurial's global settings file “mercurial.ini”.  On Windows this file is typically found in “C:\Users\<username>\mercurial.ini”.

First, make Mercurial aware of WinMerge:

[extensions]
hgext.extdiff=

[extdiff]
cmd.winmerge = C:\Program Files (x86)\WinMerge\WinMergeU.exe
opts.winmerge = /e /x /ub /wl

Then enter some more incantations:

[merge-tools]
winmerge.regkey=Software\Thingamahoochie\WinMerge\
winmerge.regname=Executable
winmerge.priority=-10
winmerge.args=/e /x /wl /ub /dl other /dr local $other $local $output
winmerge.fixeol=True
winmerge.checkchanged=True
winmerge.gui=True
winmerge.diffargs=/r /e /x /ub /wl /dl '$plabel1' /dr '$clabel' $parent $child
winmerge.diff3args=
winmerge.dirdiff=True

Now you're set to fire it up from the command line:

1) Update your working copy to one of the branches you're interested in diffing:

C:\Repository\Spike\Android>hg up fembot-firmware-upgrade-branch

2) Launch winmerge passing the branch name (or revision number) that you want to see the diff of:

C:\Repository\Spike\Android>hg winmerge -r default

TAAAADAAAAA

Another way I use this is to see the difference between my working directory and my last commit:

C:\Repository\Spike\Android>hg winmerge

My team has recently made the switch from Visual Source Safe to Mercurial.  Here are some noteworthy points about this adventure:

Ability to be choosey about when to release your code

How often has this happened to your team: the source builds, and all the tests pass, so you commit your changes at the end of the day.  The next morning you’re running a little behind, and you’re greeted with the stink-eye by your colleagues.  You only half way implemented the log-in page so everyone is locked out of the application…until you fix it.  With distributed source control this problem goes away. 

Using distributed source control I can commit locally any time I want without affecting the rest of the team.  Meanwhile, I still get the ability to punt and rollback changes if and when I get too far down the wrong path. 

A nice side effect of a clean shared repository is that it’s ship-able at almost any time.

Effortless reverts/rollbacks

As soon as I’ve completed a decent chunk of work (a passing unit test or a layout change) I commit.  Commits happen in the blink of an eye, so there’s no disruption to my workflow.  Also, every time I check work in, I tag it with a 4-6 word description of what I just did.  Now I have a really nice trail of comments to show me where I’ve been.

Since the change sets are small, those commit comments become much more meaningful.  Other developers can look through the change log and pick out interesting looking changes to learn from.

Since the repository is on a local disk, reverting or rolling back changes takes one or two seconds.  Because of the speed and frictionless experience, it makes you feel much freer about using the features.  Subversion/TFS/et. al. all have the ability to revert, but it’s a process and ceremony that takes so much time that I’d rather work around it.

Safety

If you’re using distributed source control the way it was intended (small commits, pushed to a shared repository) there is almost no way to lose code.  The biggest feeling of safety I get over using traditional SCM’s is when I’m merging.  Using Subversion or TFS, if I goof a merge then my working copy is in a broken state until I rectify it.  If I’m using a distributed system and I fat finger a merge, I’m just a revert command and one second away from my pre-merged code.  After my revert I can take a deep breath and try that merge again.

Easy branching/merging

This is the one thing that everyone talks about, and it is true.  Branching and merging is effortless once you’ve unlearned what subversion and other central-control systems have taught you about it.  I found www.hginit.com to be a great way to understand the essence of distributed source control usage.

Easy integration with TeamCity

For the first time in my career, I am the guy in charge of the continuous integration server.  I was a bit daunted at the task, but TeamCity made it simple.  TeamCity’s support of Mercurial is first class and makes it simple to pull the code and build it.

GUI Tools for learning

When I first started getting a feel for distributed source control I leaned heavily on TortoiseHG.  It was a great way to visualize branching/merging and some of the other new concepts that I needed to learn.  Now that I’m a little more seasoned, I get a lot less workflow fiction by relying on the CLI.

VisualHG is a Visual Studio plugin that is a lot of help.  The primary interest I have in VisualHG is that it tracks all of the actions I take in the IDE such as adds/removes/and renames.  These actions otherwise require me to remember to make Mercurial aware of the action by using the ‘addremove’ command. 

Corrupted my repository

One word of caution: do not inadvertently touch the local repository files.  TortoiseHG by default makes copies of files that you revert.  I hadn’t noticed this until later, so I wanted to clean up all of those un-needed files.  By doing a search on the parent folder of my repository I found _all_ of those files and deleted them – including the ones that were in the repository.  Dumb.  Mercurial was very kind and told me there was a problem – and what revision I could revert back to.  To get out of that pickle, I pulled the latest version of the shared repository and merged my working copy into that.  I lost a few changesets from my local repository – but all my code was still safe from my working copy. 

Why Mercurial over Git?

A couple reasons, most of which are based on gut feel.

1) Git commands seem esoteric compared to Mercurial.  Mercurial’s commands just feel natural and like something I can easily remember.

2) Everyone raved about Mercurials Windows support, along with excellent GUI tools.  Meanwhile I heard only bad things about Git’s Windows support.

3) Codeplex began to support Mercurial, so there was an extra confidence push that raised the comfort level.

4) Martin Fowler’s article on source control management tools didn’t hurt.

5) I have to worry about line endings?  This was actually a big turn-off.

6) Git has a strong community following, but after poking around for Mercurial resources I found solid community backing there as well.

Conclusion: What you’ve been told is true, distributed source control systems are a much more natural fit than traditional SCMs.  It’s really quite difficult to explain the feeling of freedom I get when using source control that I feel works with me…but just trust me: it’s a good thing.