If the bug/change you’re trying to make is anything beyond the most trivial
task, it would be great to have your sources under version control so you have
the freedom to try things and backtrack—you know, one of the basic ideas
behind version control. So, now you’re stuck. There’s too much overhead to
create a whole new branch just for this one fix. Do you resort to renaming
files and folders and moving back and forth on your editor’s undo buffer?
C’mon now, behave.

When the tools aren’t working for you, find a new tool! Enter
Mercurial. I won’t get into the
interminable debate between Mercurial and Git and other
DVCS’s. Suffice it to say that they are all the NBT, and distributed VCS are a
superset of centralized ones. I’ve chosen Mercurial for pragmatic reasons: 1)
works well on Windows and 2) is implemented primarily in
Python.

The basic idea is, you can use Mercurial on top of your current, centralized
version control system. This way, you get all of your local sources under
version control independent of what the rest of your company uses. It’s a
simple idea, but it frees you from worrying about how to manage changes you’re
making in your local area. Another situation I frequently find this useful in
is when I’m writing a one-off script that I’m not sure if I want to commit to
the repository. But, the script is complex enough that I’ll need to iterate a
few times. Wouldn’t it be great to have it under version control? Here’s how:

Install Mercurial

I’m on Windows, so I just go for the Windows binary
package where Python and everything is all
wrapped up for you. You can also install it with cygwin, if that’s your bag.
Make sure C:\Mercurial (or wherever you installed it) is in your path.

Now, you’re good to go. The executable name is “hg” (get it?) and if you type
that without any arguments at command prompt, you will see a list of basic
commands. All the concepts of version control that you’re familiar with are
all there. Let’s walk through an example of putting your sources under version
control and making some changes.

Create a new repository

The first thing you’ll do is create a new repository from your current
sources. Let’s say you’re working on on a project in C:\projects\GoogleKiller.
Navigate to that directory, and type:

> hg init

That command should return silently. It generated a .hg folder in that
directory where the metadata is stored. You’ve just created a repository. You
can now do:

> hg status
? GoogleKiller.py
? GoogleKillerTests.py
? README.TXT

This tells you that mercurial sees three files, but none of them are tracked.
To start tracking them, simply:

> hg add
adding GoogleKiller.py
adding GoogleKillerTests.py
adding README.TXT

Without specifying any files to “hg add”, you’ve added all the files in the
directory. Now, the last step to getting these sources in the repository is:

hg commit -m "Initial checkin!"

The -m argument is the log message for the checkin. You can track the history
of commits with the log command:

> hg log
changeset:   0:8c047c4da9a4
tag:         tip
user:        bentsai@example.com
date:        Fri May 30 17:32:17 2008 -0400
summary:     Initial checkin!

Now you’re ready to roll with local version control:)

Start coding

The commandline help for mercurial is pretty good. The basic commands you’ll
care about are:

• hg status (to see what files have been modified)
• hg diff (which prints out a unified diff of what’s changed)
• hg revert (for backing out of changes)
  To get more details on these commands, just type “hg help “. There
  are other tweaks you can make to the usage (the [documentation](http://hgbook
  .red-bean.com/hgbook.html) is good), but that’s the general idea. Now you’re
  free to get on with coding!

The process for getting up and running is pretty low on friction, which is why
I like it. This doesn’t even begin to touch the real boon of DVCS’s—actually
collaborating with others. But this technique takes advantage of Mercurial’s
speed, easy-of-use, and unobtrusiveness for a rapid solution to a fairly
common problem.

Update (June 1, 2008): I should note that using Mercurial for version control isn’t limited to code. Any situation you’re keen on rolling back changes, this could work. Before I found out about Mercurial, I thought about using Subversion for such a purpose. But the pain was setting up a server – with Mercurial, there is no centralized server to setup. The only thing Mercurial does is add an “.hg” folder in the root. Once you have it installed on your computer, you’ve got localized Time Machine-like powers at your fingertips.

Update (June 2, 2008): Here’s someone who’s using Mercurial specifically with Perforce and described his workflow more extensively than I have.

:n **/*.csproj

Highly polished and impressive videos on the Essentials of Programming: hillelcoren.com/coder

— Scott Hanselman (@shanselman) January 20, 2012

I watched through the whole thing, and it is indeed an impressive collection of tips to becoming a better programmer. The videos cover a breadth of topics in a short period of time. To give you a taste, the first unit covers managing complexity, the single responsibility principle, separation of concerns, TDD and design patterns. And that’s only the first 2 minutes. The total running time is 20 minutes, so you should watch them:

The videos have a strange feel to them, since they use public domain clips overlaid with After Effects-generated titles and effects. The visuals are not crucial and more often than not, result in curious juxtapositions of software wisdom with campy footage. Regardless, the content is great.

Highly polished and impressive videos on the Essentials of Programming: hillelcoren.com/coder

— Scott Hanselman (@shanselman) January 20, 2012

I watched through the whole thing, and it is indeed an impressive collection of tips to becoming a better programmer. The videos cover a breadth of topics in a short period of time. To give you a taste, the first unit covers managing complexity, the single responsibility principle, separation of concerns, TDD and design patterns. And that’s only 2 minutes. It’s only about 20 minutes total, so you should watch them:

The videos have a strange feel to them, since they use public domain clips overlaid with After Effects-generated titles and effects. The visuals are not crucial and more often than not, result in curious juxtapositions of software wisdom with campy footage. Regardless, the content is great.

This happens occasionally with apps that don’t behave politely. As a workaround, you can retrieve the window like this:

Alt-Space M <any arrow key>, then use the mouse to move the window.

What this does is open the command window and select the Move option. The arrow key then allows the mouse to take over the move.

@bentsai “d”amn it why am i still using svn

— Ben Lowery (@blowery) January 17, 2012

.alpha60 {
    /* Fallback for web browsers that doesn't support RGBa */
    background: rgb(0, 0, 0);
    /* RGBa with 0.6 opacity */
    background: rgba(0, 0, 0, 0.6);
}

But what this feature does is reduce the friction of writing posts even more, and that is a powerful idea. Even though the text editor is fairly bare bones (no support for links, no HTML preview, no auto-save), it eliminates the overhead of navigating the file system, creating and naming a new text file, and typing in the proper header. John D. Cook wrote a post explaining this concept that a little simplicity goes a long way:

Sometimes making a task just a little simpler can make a huge difference. Making something 5% easier might make you 20% more productive. Or 100% more productive.

This is a huge reason why I’m so enamored by these blogging services that use Dropbox. There are plenty of blogging tools and services out there that make it easy to blog: Posterous, wordpress, tumblr, etc. Indeed, they’ve done a remarkable job of lowering the barrier of entry. But why do I like Scriptogram the most? It’s a little bit easier and simpler. There may actually be the same number of steps, but another component is the cognitive overload that it reduces. With Scriptogram, I’m simply editing a text file on my computer using Markdown. I’m limited by Markdown’s formatting abilities, which is a good thing. That little bit has been the deal-breaker and the reason for more posts as of late.

This also partly touches on why “simple” apps are all the rage and the notion that “less is more.” From 37 Signals’ Less Software chapter from Getting Real:

• Less software is easier to manage.
• Less software reduces your codebase and that means less maintenance busywork (and a happier staff).
• Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code.
• Less software results in fewer bugs.
• Less software means less support.

Software is incredibly complex. I want to have the minimum possible. It’s always a victory to me when I can get rid of code.