Using Decentralized Version Control for Your Presentation Demos

Occasionally, I present some slides and demo code at a local user group or event. Sometimes these demos include some code that I write throughout the presentation. By the end of the presentation, there is a bunch of code there that I did not start with.

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?