After doing a major deployment and thinking about how to manage later deployments of bug fixes it really hit me just how poor change tracking is in Teamworks. Specifically, there is basically none. Change tracking consists entirely of an audit trail that tells you who changed a file and when, but not what they changed or why they changed it.

The Teamworks change control model is a simple Check Out-Check In one. When you make a change to a file the authoring environment checks it out. This puts an exclusive lock on the file until you check it back in. If any other user wants to make edits to the file they must wait until you check it back in. This may have been state-of-the-art in the 1980s with RCS (Revision Control System), but not today.

There is also no concept of meta-data associated with these audits, meaning you can’t even associate specific changes with specific fixes. For example, say you are trying to figure out which three services you edited to fix a bug from six months ago similar to one that just cropped up. There is no way for you to find those changes. This makes the audit trail essentially useless for auditing. A change that tidies up the layout looks exactly the same as a change that rewrites the whole service. Its only seeming use is seeing who last edited a file when I need it so I can tell them to check it back in if they are done with it.

Supposedly Teamworks 7 will have real version control, but I am skeptical. First, this is a pretty essential feature to get to version 6 and still not have. To me it shows that they are not dogfooding their product in any meaningful manner. Second, having spoken to a couple of consultants about the new version control coming to version 7 I have real fears that they are implementing their own solution instead of integrating something like Subversion. If this is true it is pretty much guaranteed to be buggy.