Let's go over what doesn't work shall we?
* Everyone, and I mean everyone hijacks files instead of reserving them. This wonderful tool has no mechanism to enforce this and the result is that people hijack the files, change them, commit them. If someone works or worked on that same file they'll see their work over written. I see this almost daily because guess what, developers don't talk to each other.
* Can't trust CC to merge right. I work in a multi platform environment and one day i decided to find/replace CR+LF in a file. 16 hours later another developer and I were done recovering the mangled file. (yeah yeah get the previous version; sure we did that and then hand merged 4 peoples code by hand)
* Several parts of the GUI crash pretty consistently. About 40% of my colleagues can't use the versioning "tool" because it crashes on launch. The other 60% don't use it because it is useless. There are several other parts that crash randomly as well. It is an unstable product.
* Committing had too many steps; if a user forgets one he/she locks part of the tree for the build person.
* People distrust the tool so much that directories appear inside the tree to version binaries.
* The amount of data that flows over the wire to commit a trivial change is in the 100s of megabytes. I once measured it for a file that was 800k. Over 200mb down and over 102mb up. They advertise that it is less network intensive than CVS; ha!
* People hand merge changes because the mergetool sometimes looses changes or shuffles them. So overhead was easily quadrupled since introduction.
* many many many more other flaws that i don't care to note.
CC is what I call tit-ware. As a sales guy you take a potential customer VP out to a titty bar; get some pictures for leverage; and then he will have to purchase it.
CVS isn't the best but I can promise you that spending millions on any rational/IBM tool is a complete waste. Don't even know why you brought it up but I couldn't help myself but respond.
On May 4, 2005, at 6:23 AM, Alan Finlay wrote:
I have done significant work with ClearCase and CVS in a software development team environment, and some minor work with other revision control tools. Team size for ClearCase was around 20 developers, and with CVS around 10 developers. For an open source project like OpenBSD, CVS is quite likely the best choice, but for other situations ClearCase has advantages. ClearCase has file locking per branch, but branching is lightweight and the branch merging tools are convenient (i.e. they work) unlike those for CVS. Branching is convenient (branch merging works) because ClearCase has revision control of directories as well as for files which is a serious lack for CVS.
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
