Why do version control? I remember the first time I learned about version control. It was for a SunOS based project, and my manager told me to learn SCCS, and put all of our sources in it. Its been years since I've used SCCS, and I am not always sure if it had features I also remember in RCS and PVCS. They are all similar tools. Since those younger years, I've learned that version control is much more than a glorified file repository, and has more to do with people working toghether, collaborating on their project code base.
Archiving and Submitting Changes
As far as I could learn, SCCS was an archiving tool. It saved a history of the code. I could use it to see a history of comments, and compare different revisions of each file. I didn't know anything about tags or labels, or branches, or merging.
Not long afterwards, I worked in a PVCS development environment. There, we used version control as a means of passing changed code to a build and release process. We used labels to mark a stable set of files to build. I recall this being an upgrade from maintaining a file revision list file when working with RCS. So, version control was a code release tool.
For some time, I worked in a project with CVS. It was still being used as a release tool, being the feed to an automated build and release process. We placed tags on the archives according to a fixed time, the deadline for committing changes. I got a hint of the potential of using version control as a collaboration tool, but I still saw its primary functions as archive, history, and code submissions.
Parallel Development and Collaboration
Then I learned and used ClearCase. It blew me away. I won't argue the complexity of the tool, and perhaps the difficulty of deploying it. But, as far as version control goes, it enlightened me to the concept of parallel development and continuous integration. I was still in the mindset of an archiving and code release tool, but now I could see how one could organize a development organization such that no one has to wait on a locked file, or on a code freeze to work on their features and fixes.
For me, ClearCase showed me how version control is best used as a code development collaboration tool. What I mean is, the primary objective of putting code in version control is to enable others to share in the development process on the same code. The entire team owns the entire source code base, and when all members of the team participate in the integration and build process, all the better.
In Conclusion
Obviously, ClearCase is not the end all and be all in collaborative development, and now that I look back on CVS and PVCS (not so much SCCS) I can see how to deploy them as code development collaboration tools. When I see more recent products (Perforce, Subversions, Visual Source Safe and so forth) I evaluate them based on the merits of a collaboration tool, and less on archiving and code submission, though those are also basic requirements. I won't comment here on which tools I like best.
When someone says, "Let's store all the released binaries in ClearCase," I cringe. Then I explain that ClearCase is best suited for code development efforts, and we have better, easier to manage, tools for archiving product releases.
In summary, to me, the purpose of a version control tool, and in fact other development process tools like issue tracking, is to promote cooperation within a development team. I look at my job as reducing the barriers to collaborating on the code base of a project, and version control is one of my means to that end.
