In the description below I explain how for ClearCase using dynamic views and per feature branches it is possible to get the same ways of working as with CVS and with many other benefits CVS does not have. I have no connection with Rational/IBM, but I wish to dispel the misconception that only a non-locking revision control system allows the development style CVS encourages.
By creating a branch per minor feature, e.g. one for each bug fix, one for each small team working together on a feature, the locking is very helpful at alerting team members of conflicts when working on the same area of code (assuming your source files are organized sensibly), its then usually easy to work out a strategy to not break the system. Sometimes waiting an hour or two and working on something else so the updates can be done sequentially can save the bother of a merge. In this way teams working in different branches generally don't need to be aware of source file conflicts until branch merging, and the automatic merge usually handles most of the merges correctly. When you have both altered the same line of code in different branches, a manual merge will be needed as is done with CVS within a branch, but you should have been aware of that before the merge - i.e. I'm not suggesting ClearCase branch level locking means you don't need to plan/communicate and thereby avoid conflicts in advance. In my experience with this style, usually a single developer is using a branch exclusively, so the locking has no impact at all on other developers. Hence each developer or small team can choose if they want to use locking to communicate or not at any stage in the development process by creating suitable sub-branches as deeply nested as they like.
Using minor branches for each development task in ClearCase gives much the same benefits as the non-locking checkout provided by CVS. Also the branches provide a record of what changes were made for a bugfix or feature with easy access to a list of all the files affected and which versions of those files. Another benefit of lightweight branching is that developers can use a private branch and checkin incomplete work at checkpoints convenient to themselves without worrying that others will be affected by this work in progress. Branches in CVS are too heavyweight to do this and when using CVS I am tempted to use a private revision control system to manage my own checkpoints when the CVS branch is being shared by the team.
ClearCase also allows you to make an unreserved checkout (i.e. one which does not lock the file at all, or to checkout a file already locked exclusively by someone else), however by doing this you clearly signal to the team that you are responsible to clean up any consequences (e.g. this is no excuse for a lost update).
To get the full benefit of ClearCase you should use dynamic views, the snapshot views are inconvenient since checkouts of minor branches copy every file to a local workspace and are too slow to create. Dynamic views only copy a file from the repository when you checkout the file, the files you have not changed are accessed in a way similar to NFS using the remote repository as the server. You need dynamic views for the flexibility to use ClearCase efficiently since changing views (i.e. altering the viewspec which determines what a view sees) is then efficient. This makes quick branch comparisons and builds which lock out or pull in changes defined in various ways a convenient way to work.
The downside for ClearCase is that it is both time and money expensive. In terms of time, it requires a dedicated maintainer or significant training for the whole team since ClearCase is complex to administer, especially if you are using Multisite (for mirror repository synchronization), and/or using dynamic views.
Personally I would avoid using cost of the product as the determining factor in a commercial environment - its usually false economy. I wouldn't use ClearCase unless it has a champion in the team since it is complex when used effectively. A team accustomed to locking may find the switch to CVS uncomfortable, but if they have been accustomed to revision control of directories they will be downright annoyed if given a system without it.
Alan Finlay
----- Original Message ----- From: "Roy Morris" <[EMAIL PROTECTED]>
To: <misc@openbsd.org>
Sent: Tuesday, May 03, 2005 4:50 AM
Subject: CVS - Lock File
Our company has started to look at CVS as an alternative to our current products. When I suggested using CVS I was told not having a lock file or method of knowing who was working on some code was going to be unmanageable. (and nearly beaten to death, by the developers)
Since Openbsd has the OpenCVS project, I thought you all might be the best people to ask about this. Is this really going to be an issue for a handful of developers?
Thanks in advance for your comments.
Roy Morris
