Eric says “One of the best practices I suggest in Source Control HOWTO is to never use a version control feature which encourages you to checkin code which you have never been allowed to compile and test.”

I agree 100% with that “best practice” when using a centralized version control system. But Git, Bazaar and friends are not centralized version control systems. They are decentralized.

With a decentralized version control system, your commits are decoupled from your compiles and tests. Your commits are decoupled from your build server. Your commits are decentralized from any team process or build process system. Remember that “check in” or “commit” in a distributed version control system just means “hey, I might want to come back to this at some point in time”. They key word there being “I”. Its about you as a single developer. Its about being selfish. Its about being able to work without barriers. Its about being able to make large sweeping changes and then rollback all but some of them and then merge only those changes which you want with your teams branch.

Ok, so Eric ends his post saying “That doesn’t mean Git or its index are bad.  I’ll agree that "git add –p" is a very powerful feature that has its place.  But in this respect, Git is a bit like C.”

Fair enough Eric. Eric knows that this is a powerful tool to be used carefully by a skilled craftsperson. That is what we are as programmers.

If C’s killer feature is casting an int to a pointer, then Ruby’s killer feature is open classes. Sure, it can be a confusing tool to the uninitiated, but ask a well versed programmer to not use that tool and I would encourage them to call you crazy.

Don’t fear your tools. Master them. They will server you longer than any fear will.

I’m very glad that Eric says that “no book on this topic can be truly credible these days without covering distributed version control tools”. He says these tools aren’t mainstream yet, but with ruby forge, linux and github using git and with Ubuntu, mysql, Mainman and squid using Bazaar, DVCS is mainstream.

Problem: next time I give the presentation, invariably, I have forgotten to go back and reset things so that my code files don’t have the code to be written in them.

Solution: use a decentralized version control system for presentation demo code.

It doesn’t matter if it is Bazaar (the best), Git or Mercurial (the others). Use one of them!

Use looks like this:

1. Prep your demo project with the files to be handled when you start your presentation
2. bzr init ; bzr add ; bzr commit –m ‘initial check in’
3. Give your presentation. When you are done, run bzr revert. You need not even commit the changes.

Sure, its pretty much the same as making a backup, but when you invariably forget to remove the post-presentation written code, you can simply type bzr revert. Typing one command that is not prone to error is a lot easier than doing the “remove folder, rename folder” dance.

For longer presentations like 1/2 day or day long tutorials or multi day classroom training, you can break your code into stages. Just commit at every stage. Then you can bzr revert –r 2 to get to your 2nd stage code, bzr revert –r 4 to get to the tail end of the day, etc.

You can even use loggerhead to show your class participants differences between revisions, or even just bzr diff output. You will be able to show people a different view of the evolution of your project, which hopefully will give them new understanding and more clarity. This is why we use these tools, right?