Rolling Back to Old Versions of Files in CVS

We use CVS on many of our projects. CVS allows several developers to collaborate on the same file, tracking their changes and merging them. At RD2, we use a program on our Windows machines called Tortoise CVS to interface with the CVS server. Tortoise CVS provides a friendlier interface to using CVS than using the command line (unless that floats your boat!).

Last week, in the course of developing a page for one of our clients, I determined that the route I was taking (and the changes I had “committed” to the CVS server) was not the direction I wanted to go, and needed to roll back to a previous version of the file. That’s one of the neat things about CVS — each time a developer “commits” their changes, a new version number is created. At any time, you can see what has changed between versions. In this case, I was up to version 1.10, but wanted to revert to version 1.08.

This is when things got tricky.

Thinking that it would roll back the version for all users, I right-clicked the file I was working on in my Explorer window and selected the CVS History. CVS History shows a log of all the versions of the file, who committed it to the CVS server, when it was committed, and any commentary provided by the person who committed the file. In the CVS History menu, I right-clicked on the version I wanted to roll back to (1.08) and selected “Get this revision (sticky)” thinking that meant every user would now see 1.08 as their version next time they “updated” their files. I was wrong.

“Get this revision (sticky)” acquires the file for only the user that selects it. “Sticky” also locks the file for that user (in this case, me!), not allowing them to commit changes to the file. This is because the server is sitting at version 1.10 and changes can’t be made to versions from the past. I was trying to update 1.08, but changes to it were no longer allowed.

In searching for a solution for the dilemma I created for myself, I had some difficulty locating the exact answer I needed (hopefully Google will find this post and help the search results be better).

After a bit of research and some playing around, I learned that to get out of this mess, I needed to do an “Update Special”. From that menu, I selected “Get tag/branch/revision” and “HEAD” from the dropdown menu. This released the “Sticky” issue I had, because it grabbed the latest version (1.10) and replaced the 1.08 version I had acquired and locked down locally. Selecting “HEAD” may not always work, dependent on your particular CVS configuration and the structure you have set up with a project.

The next step, and what I should have done originally, is selecting “Save this revision as…” and overwriting the local copy of the file. From there, update and commit the file. In this example, the CVS server would then make the committed file version 1.11.

For more on CVS, check out Introduction to CVS, Getting Started with CVS, or CVS Overview.