Plan for Software Carpentry 2012 Boot Camp on Version Control¶

Purpose¶

To explain version control to researchers who have never used it before, or who want to understand it better.

Context¶

Two hour interactive live workshop, using EasyMercurial and the Mercurial command-line tool.

Outline¶

The basic plan is:

1. presentation introduction to version control in general (using either whiteboard drawings or a PowerPoint presentation)
2. long worked example in which basic topics of version control are worked through using EasyMercurial and then some more advanced topics are returned to using the command-line tool
3. closing remarks talking about other tools, other topics of interest etc

Contents¶

Detailed contents:

• A presentation introduction to the concept of version control.
  • What is it for and why is it useful?
  • What can go wrong without it?
  • How does a version control system work?
  • History + Collaboration
• Check that participants have EasyMercurial installed and working
• Worked example, part 1: Working by myself
  • Topics: Initialising a repository, committing files, reading history, looking at diffs, reverting unwanted changes, going back in time to look at old versions
  • We will be working on a recipe for fish stew for a future recipe book
  • Make a new directory, create a text file fishstew.txt in it, start adding an ingredients list, save
  • Run up EasyMercurial, "Open" that directory, see fishstew.txt in untracked file list, explain this
  • Add file, commit, supply a message, note that we now have some history
  • Make a change, note that files are marked as modified, note possible presence of backup file (ending ~ or .bak) from editor -- we'll come back to that
  • A changeset records the state of all files, not just one file: add another file, omelette.txt and add that
  • Commit change, review history, look at the diff
  • Digression: every action we're taking here corresponds to one command-line command: show hg log, hg diff etc
  • Go back to that backup file in My Work, add it to ignored list, commit
  • The history is not just for information: we can go back to the previous version by updating to it...
  • ... and then a normal update gets us back to the latest version again
  • Now, let's say this is the version we send off to our agent to see whether (s)he can sell it to a publisher. (Or whatever we do these days.) Tag it as v0.1 -- digression about sensible tag names on whiteboard?
  • Make and commit another change, just to make the history more interesting
  • What if we make a change and decide we don't want to commit it? Edit something, then hit Revert
• Worked example, part 2: Working by myself with backups