Revision Control in Tivoli

You'd think working for IBM's Software Group would mean we have revision control sorted, right? Well, not quite. We use an internal system called CMVC - Configuration Management Version Control. There's no reliable integration into developer's tools (such as Eclipse); you can use either a command-line interface or a dated Java GUI. The servers are based in Austin, so it's slow to work with from Australia.

It does have strengths though, mostly around it's integration of defect management with source control. This tends to lead people towards the "one defect, one commit" policy I mentioned earlier, however it does come with overhead. My process to check in some source changes are as follows:

  1. Create a defect, if one doesn't already exist for the change I'm making.
  2. Modify the owner of the defect to be me, rather than the owner of the "component" the defect was raised against.
  3. Accept the defect.
  4. Create a track for the defect.
  5. Select the files I want to modify from a list of all the files in the release (or component). Make sure I don't unselect the list of files!
  6. Use a diff tool to merge the local changes into the checked out files. This isn't a case of copying the modified files, as there are version control flags like '%F%X' that need to be preserved in the checked out files.
  7. Using the file list selected earlier, check in the changed files.
  8. If you didn't change a checked out file, "unlock" it.
  9. Each "component" that contains a file you modified now has a "fix record". Set all these fix records to "complete."
  10. When all the fix records are complete, the track you created earlier should now be in the "integrate" state. Make sure this happens, else your code won't be included in the next build.
  11. To make sure our local (ie not in Austin) copy of the backing source gets updated, kick off a script on an internal server to extract the changed files.

Sounds complicated? It is. No wonder so many teams use CVS locally and push changes across the Pacific once a week. In the system's defense, it's not designed for rapidly changing development environments. It's strength is in tracking and managing changes caused by discovered defects in stable code bases.

While there may be newer and better alternatives, this does the job and does it without breaking. Mostly.

blog comments powered by Disqus