History: Confronting your Past


But that doesn't mean I have to be happy about it.

Another important feature is the ability to view and browse historical versions of the repository.  In its simplest form, this can be just a list of changes with the following information about each change:

  • What was changed
  • When the change was made
  • Who did it
  • Why (the comment entered at checkin time)

But without a way of filtering and sorting this information, using history is like trying to take a drink from a fire hose.  Fortunately, most SCM tools provide plenty of flexibility in helping you see the data you need.

In CVS, history is obtained using the 'cvs log' command.  In the Vault GUI client, we use the History Explorer.  In either case, the first way to filter history is to decide where to invoke the command.  Requesting the full history from the root folder of a repository is like the aforementioned fire hose.  Instead, invoke the command on a subfolder or even on a file.  In this way, you will only see the changes which have been made to the item you selected.

Most SCM tools provide other ways of filtering history information as well:

  • Show only changes made during a specific range of dates
  • Show only changes made by a specific user
  • Show only changes made to files of a certain extension
  • Show only changes where the checkin comment contains specific words

The following screendump from Vault shows all the changes I made to one of the Vault libraries during October 2004:

Best Practice: Do as I say, not as I do
It is while using the history features of an SCM tool that we notice what a lousy job our developers do on their checkin comments. Please, make your checkin comments as complete as possible. The screen dump above contains an example of checkin comments written by a slacker who was in too much of a hurry.

Sometimes the history features of your SCM tool are used merely to figure out what happened in the past, but often we need to dig even deeper. Perhaps we want to retrieve ("get") an old version? Perhaps we want to diff against an old version, or diff two old versions against each other? We may want to apply a label to a version that happened in the past. We may even want to use an old version as the starting point for a new branch. Good SCM tools make all of these things easy to do.

A Word About Changesets and History
For tools like Subversion and Vault which support atomic transactions and changesets, history can be slightly different.  Because changesets are a grouping of individual changes, history is no longer just a flat list of individuals changes, but rather, can now be viewed as a hierarchy which is two levels deep.

To ease the transition for SourceSafe users, Vault allows history to be viewed either way.  You can ask Vault's History Explorer to display individual changes.  Or, you can ask to see a list of changesets, each of which can be expanded to see the individual changes contained inside it.  Personally, I prefer the changeset-oriented view.  I like the mindset of thinking about the history of my repository in terms of groups of related changes.

Vault has a feature which can produce an HTML view of a file with each line annotated with information about the last person who changed that line.  We call this feature "Blame."  For example, the following screen dump shows the Blame output for the source code to the Vault command

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.