Requiring Comments for Subversion Commits

One of the cool things about DreamHost is that it offers a free Subversion repository with its hosting package.  While it provides a convenient interface to set up a project repository, some things need to be configured manually.

When I checked in some code for today, I forgot to enter a comment for the commit.  There were no pre-commit hooks in place so the commit went through as it normally would.  This is undesired if I want to go back and revisit a specific change in the future by viewing the commit comments.

How do I make sure this doesn’t happen again?  There are a handful of sites online that offer solutions for this situation.  One that provided the most direct answer was from Word Aligned.  To add a pre-commit hook to block checkins containing empty comments, use the pre-commit script template file contained in the hooks directory of the Subversion repository.  Assuming you have access to the repository server:

1) Go to the hooks directory for your repository:


2) Copy the existing precommit-tmpl file to a file pre-commit

cp pre-commit.tmpl pre-commit

3) Make the new file executable

chmod +x pre-commit

One caveat is I commented out the following lines in the pre-commit script since I did not need to fine-tune access control for the time being (nor are the required files present by default in the hooks directory):

# Check that the author of this commit has the rights to perform
# the commit on the files and directories being modified.
"$REPOS"/hooks/ "$REPOS" $TXN \

That’s all there was to it for my situation.  See the Word Aligned article for details on testing the hook script and this person’s blog post for information on setting up

Leave a comment

Posted by on April 14, 2012 in How Tos


Tags: , , ,

To www, or not to www.

After setting this site up on WordPress (way easier than I expected), one of the first things I noticed when navigating to “” was that “www” was getting attached to the front of the URL, resulting in “” in my browser’s address bar.  This came as a surprise because I specifically configured the site to accept both www and non-www forms without redirecting to either.  I configured this setting via DreamHost’s Domain Management Panel (DreamHost is the company that hosts this site).  As I have other sites configured the same way and working as such, it was a bit of a mystery why this site was misbehaving.

I mentioned this to a buddy at work and he quickly pointed me to Matt Cutt’s blog entry on URL canonicalization.  A very interesting read.  Apparently, using both www and non-www forms of a site’s URL isn’t recommended in terms of SEO.  When building links to various pages of a site, it’s best to stay consistent so that search engines don’t have to try to decide between multiple similar URLs.  My initial decision to drop the ‘www’ was mostly for aesthetics and brevity, but after reading the article it made even more sense to do it.

Back to my issue.  Why was this site redirecting?  Viewing Firebug’s Net tab while loading the page revealed the answer.  The request was returning a 301 status code and signalling the browser to redirect to the “www” address of the site.  To add insult to injury, Firebug’s waterfall chart showed 600-800ms of added page load time due to this redirect.  As a web performance junkie, this was completely unacceptable.

Firebug's Net Tab showing 301 status code and redirect latency

Firebug's Net Tab showing 301 status code and redirect latency

Evidence of my admitted WordPress-newbiness, the solution was simply in WordPress’s General Settings Page.  All I had to do was change the WordPress and Site Address URLs to their non-www versions and my redirect woes were soon gone.

Leave a comment

Posted by on March 28, 2012 in Performance


Tags: , , ,

Hello world!

WordPress’s famous 5-minute installation is stuff of legend. is online!

1 Comment

Posted by on March 27, 2012 in Announcements