We use Clearcase at our office, and based on my admittedly light knowledge of clearcase, it just seems like a really bloated source control tool.
I know from hearing friends talk about Clearcase that it's really powerful. My question is, what are some features of Clearcase that make it 'powerful', and what are good tips and tricks for getting the most out of Clearcase?
On my current project, we're using ClearCase. To be honest, most of the development team wants to switch to Subversion, but we cannot for political reasons.
First off, if you can afford devoting folks to SCM work, I would recommend doing so. SCM work is not just about making sure ClearCase works. You also want to be able track whether commits are tied to your issue tracking database, and whether it ties into your continuous build scripts (we're using CruiseControl). This applies to any VCS.
Second, be sure to make sure your development team is using the same diff tool. I've found BeyondCompare to be the best, though I'd be happy to settle on WinMerge if money is tight.
Third, one really great thing about ClearCase is that it can show an entire version tree with branches and merges for the change sets with respect to a given file. Keep this working, because it is very useful for doing "code archeology". E.g. sometimes when I need to track down the source of a bug, the CC version tree tool helps me to chase down the person who introduced the change that introduced the bug.
Fourth, I would watch carefully for how your version of ClearCase handles merges. Yes, its merge algorithms have gotten better with successive releases, but we've been burned by ClearCase's merge algorithms making mistakes (especially when it hasn't capitalized on smarter knowledge of the syntax tree for a given file type).
This is a good example of a loaded Question :-)
However, trying to keep it simple, here are the two key features I love about Clearcase.
Multisite capabilities (IF you have geographically separated regions with shared AND co-dependent development work)
Strong branching and merging capabilities (A boon especially for large teams with serious parallel development going on)
There are of course many other advantages, but first, I think it would be worthwhile to list down what YOU want to achieve w.r.t version control and configuration management in general. Then there could be a more specific discussion to see how (or IF) clearcase can help you achieve these goals. IMO that approach might be of more help to you since this is such a broad topic.
Hope to hear more on this.
One of the key features of Clearcase compared to at least some other VCS is the strong versioning (and branching) of directories. Only today, I checked in a cleanup to the top level directories of two of the main VOBs that we use. In one, I had removed over 60 obsolete files; in the other, over 80. Those should have been removed long ago. But they are only removed from view. If anything has gone missing that needs to be recovered, it is all still there in the VOB, ready to go.
Clearcase also supports file renaming too.
I'm not sure which of the other VCS support directory versioning.
Used carefully, the ability to branch directories is invaluable. Used carelessly, it is a recipe for confusion bordering on disaster.
It doesn't just seem like it. It really is a bloated development tool.
I don't have much useful to add, as I'm currently finishing up the first (and last hopefully) project where I used clearcase, and am on SO killing a couple of hours till punch out :P
I never found any good ways to "leverage" clearcase at all. It was more about figuring out how to tolerate it.
Setting up an unofficial GIT parallel source control system with your team was about the most effective thing we did. You can use clearcase to check files in/out from the repository into a local dir, then set it up as a git repo, add the files to it, then clone that repo into another local dir.
From there you can work normally (without CC's irritating check in/out setup), branch, share code with other co-worers etc.
When you're done with a piece of work, just pull it from the work repo, to the clearcase mirror repo. Add your changes to CC, then deliver it to the integration stream to keep the official powers that be happy.
Beware though, this approach REALLY highlights CC's shortcomings, and will likely make you dislike it even more. For instance, git took 10s to merge a large number of changes automatically. CC took 50 minutes to do the same thing, and required all sorts of manual baby sitting.
CC is bloated and needs a stupid amount of hardware resources assigned to it in my experience, but it's a really great tool. Funnily enough, I never really appreciated it until I left that place and went to another job where I had to use Subversion instead.
What is so great about it?
To be fair, here's what I really dislike about it:
The one historic feature that ClearCase has over its competitor is the dynamic views: that MVFS (Multi Version fileSystem) allowing to access files over the network rather than downloading them on the hard drive.
This is not the only way to work with those files: you can combine snapshot views (your classical "workspace") and dynamic views, but it is really useful.
The other powerful features are are based on simple concepts:
Then there is UCM (Unified Change Management) which introduces some interesting best practices (like the baselines: a label put on a complete set of file: the component, and which can not be moved - that avoid nasty surprises ;) -)
In my opinion, a correct use of UCM is the fastest way to leverage ClearCase features, provided you use the UCM streams (set of labels, and pattern for branches) wisely, that is to represent a development effort (current dev, patch, refactoring, assembly, ...), and not just to build a private workspace for a development: myStream is wrong: stream_dev is better. (If you have 15 developers with their own streams, you set yourself for countless merges back and force between the different branches associates with those streams!).
Basic rule of thumb: the name of a stream must represent a development effort, not the name of a resource (developer). The effort is here to stay, the developer can come and go.
The other best practice is the merges in UCM: they come with their own semantic based on the stream organization: "deliver" for merge from sub-stream to other streams, "rebase" for merges from parent stream to child stream.
In the end, those are still classical merges, but I find them very easy to explain to developers, and they can organize their "workflow of merges" based on a true development lifecycle very easily.
The notion of activity (or changeset) comes also in UCM and is very useful to detail his/her work.
I will not detail here the drawbacks and quirks of ClearCase since it is not the question ;)
I think the two most under-used features of base Clearcase right now are
clearmake and DOs allow a tremendous improvement in C/C++ build speed, but some people don't take full advantage.
CCRC is very useful for remote users, but is also a great tool for allowing Java developers to do work from their local machine, improving compilation time dramatically.
I agree all the positive feedbacks about CC, BUT I hate its GUI and Extensibility
I agree with all above. I think UCM is the most significant one.
If you want to make your ClearCase work better, you can try the following new ClearCase add-on solutions:
ClearCheck - Check your ClearCase database integrity on a daily basis
ClearEnv - Centralized management of ClearCase environments over ClearCase UCM
Don't you think most of people telling SVN is good and Clearcase is bad just tell so because they didn't even give a chance to Clearcase? I mean, a correctly set up clearcase (no UCM please!!!) is far much better than SVN:
The two ones above are enough to go for CC
One of my favorite features in ClearCase is that every change to the vob is simply a revision to the vob, from deleting a file to making a merge to making a checkin. For example, if your merge goes poorly, you can completely undo it simply by undoing that change. Deleted a file, but then decided you actually wanted it? Good news, the 'delete' operation was simply a change to the folder's contents. You can roll back to the folder's previous version and your file returns.
The Version Tree, as others mentioned, is a fantastic piece of work. In a few seconds you can see the entire history of any file or folder, with all its branches and versions. You can manipulate it the version tree to get at just the branches you want, then quickly compare between any version of the file.
I have no complaints about the built in merge tools. They get it right almost all the time, and the diff viewer is pretty fine.
The trigger system is very flexible. This is the make or break for most clearcase installations, I think. If you have a good set of triggers (auto-delete 0 branches, force comments, check for duplicates, ensure bad branches don't get made, others as you see fit) the system will flex and bend to your will. Bad or no triggers and you'll probably have a less than futfilling experience.
Be warned: there is a lot of overhead and knowledge needed to use ClearCase effectively. When I started using Clearcase in general, I hated it - config specs, viewer this, vob that, why do I need three views just to look at my three branches, etc. In addition, the CCRC that is in the works has different behavior in many places, and looks like it will become the new standard client for clearcase. However if you can crest that hill and get to a level of understanding of the system, you can make it sway and bend to your will with ease.
I used ClearCase (on Windows) for a project about ten years ago and have felt poor in comparison with every VCS I've used since. Mind you that was my first exposure to VCS so I might be viewing it through slightly rose-tinted spectacles. The things that I really liked about ClearCase were:
clearmake and the audit records (config record, can't remember the exact name) that were produced (every version of every file identified as it built your code, and then you can label everything based on the audit record)
I always thought the version selection language for views was superb and loved the flexibility + the selective branching (give all the files under this directory from this released version of the component but if I make any changes, check it in as part of this branch).
For graphical merge operations, KDiff3 has integration support for clearcase, and I find that program to be much better than the default clearcase diff program.
In case you want to do partial merges, cleartool merge -insert can be used.
Alternatively you can also just give three arguments to kdiff3. Say you want to merge changes from version 5 to 12 of branch1 and have checked out version 3 from branch2.
cleartool co -nc file
kdiff3 file@/main/branch1/5 file@/main/branch1/12 file@/main/branch2/3 -o file
First advice for long and complicated merges, do not try it on a working branch.
A findmerge -preview is a good way to evaluate the extent of the merge to be
try to be in a state when you have to merge the latest versions of all files of a given tree from a branch to another instead of some version of a subset of those files.
In the former case, findmerge will handle that without any problem (or "deliver" if this is UCM)