It depends in fact how you use ClearCase now, i.e. comparing to UCM, you might not lose anything valuable: you lost it already!
UCM is not ClearCase. It is in fact significantly less powerful and less interesting than base ClearCase.
So, while I can dp nothing about the cost of licenses, I could suggest you give a look at http://search.cpan.org/~dsb/ClearCase-Wrapper-1.17/Wrapper.pm on CPAN.
What I attempt to achieve there is to provide support for delivering [b]in-place[/b]. This is essential to promote derived objects which would have been produced before the delivery: delivering by merging (back) to an integration branch jeopardizes this, which ruins any chance of the .JAVAC mechanism of clearmake to compete against brute force methods implemented in ant or maven.
It also fixes most of the artificial problems created by branching strategies based on merging back, and related to MultiSite and mastership, as well as to performance and irreversibility, etc.
My analysis is that supporting a strategy of delivering by labeling required mostly to solve two problems:
- avoiding cascading forever
- getting some kind of incremental labels
This is what my wrapper does, down to handling the consequences of its changes (e.g. with providing an lsgenealogy function to replace the becoming inadequate lsvtree).
Note that I also submitted my wrapper as an RFE to IBM: http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=258...
Marc
