Ivan

Version Control (part 1)

Version Control seemed like a boring beaurocratic irrelevance when I
heard about it at university. It sounded like something that I would
be subjected to in the big bad "real world" - nothing in it for me -
but I could see why it might be necessary. These days (since about 9
years ago), I consider it a liberating and useful tool that I wouldn't
be without either at work programming in a team, or at home writing
blog articles by myself. This is an article for those who don't feel
the same, or don't know what I'm on about.

In this article, I'll try to explain what is so great about version
control by means of an example. In a future article I'll explain how
to set up and use Subversion, a simple to use, yet "industrial
strength", version control system, to get the most benefits with the
smallest amount of effort.

Consider the writing of a small program, in this case in the language
"jPoetry.NET". First, I create a new text file somewhere called
"poem.txt".

I walked around for a bit,
then suddenly saw some flowers;
they were cool.

hmmm. Not very poetic. Nevermind, I'll save this in version control anyway.

Accidents happen

After such a long time working without a break - by my standards - I
go to get a cup of tea. While I'm in the kitchen, the cat sits on the
keyboard and deletes the file (particularly unfortunate considering
that I don't have a cat).

I retrieve the poem from version control and continue with my efforts.

I walked around by myself for a bit,
like a jellyfish floating in the sea,
then suddenly saw some flowers;
they were cool.

Still not great, but I check in again.

Version Control for Debugging

I edit a bit more:

I swam around by myself for a bit,
like a jellyfish floating in the sea,
then suddenly saw some flowers;
I was rather suprised to see flowers in the sea, but there you go.

Oh dear - I've really messed up the poem - it's not "working" any
more. Rather than continue to hack around with the poem until I get it
work, which would probably mean adding hack upon hack, I use version
control to help me work out where it all went wrong.
I look at what I've changed since I last checked in to see if that
gives me any clues (if I had a realistic number of changes then I
wouldn't necessarily be able to remember exactly what I had changed).
The version control system has a way to show me the difference between
what I've got now, and what I had when I last checked in.

I see the two changes - to the first line where I changed "walked" to "swam",
and the last line, where I really bodged up the poem when I was trying
to keep it working. Rather than continue, I "revert" the changes; i.e.
return to how the poem was when I last checked in and try again.

I walked around by myself for a bit,
like a cloud floating over the vales and hills,
then suddenly saw some flowers;
they were cool.

I like this new change - the poem works - so I check in.

Check what you are committing

I work on the poem a bit more, during which time I've put in some debugging code to see whether the poem is really working correctly:

I walked around by myself for a bit, feeling a bit lonely,
Console.writeln("the first line just about worked")
like a cloud floating over the vales and hills,
then suddenly saw some flowers;
they were cool.

Before checking in, I always check through my outgoing changes. For this check-in I notice that I left the "Console.writeln" in the poem. I don't check this in, instead, I delete that line and then check-in:

I walked around by myself for a bit, feeling a bit lonely,
like a cloud floating over the vales and hills,
then suddenly saw some flowers;
they were cool.

More soon

In "Version Control part 2" I'll explain how to set up Subversion, a simple-to-use but industrial strength version control system. In "Version Control part 3" I'll explain how version control helps when working in a team.

Many thanks to Nat Pryce for his constructive comments on this article.

Posted by ivan at March 30, 2005 5:13 PM