I recently starting using Clearcase for versioning, at work. I come from a CVS background, so initially found it to be cumbersome. For example, here is how i added a file to the repository:
CVS method:
# Change to your already checked out working folder
cd /your/working/dir
# list folder contents, will see checked out working files
ls -l
# List status of all the files, (optionally, update if needed)
cvs -qn up
# copy in new file to commit
cp ~/yourfile.sh .
# add file to repository
cvs add yourfile.sh
# commit changes, and make add permanent
cvs commit -m "commit message"
Clearcase method:
# Change to your pre-defined clearcase VOB top level folder (will be empty)
cd /your/working/dir
# set your view
cleartool setview [viewname]
# list folder contents, will see working files through "this view"
ls -l
# List status of all the files
cleartool ls -l
# Make current folder checked out for modifications, -nc means no comment
cleartool co -nc .
# copy in new file to commit
cp ~/yourfile.sh
# make new file a new element, and check it in (just like cvs add)
ct mkelem -ci yourfile.sh -c "commit message"
# check in current folder, as modifications are done, -nc means no comment
cleartool ci -nc .
# end your view. your folder is now empty
cleartool endview [viewname]
# release your license (if needed)
clearlicense -release
See? CVS is simpler. But you have to work with what you have. I can see the benefit of Clearcase in a complex development environment. Expect to hear more from me on this tool from IBM.
Josh said,
May 9, 2007 @ 07:15
I thought this YouTube video showing ClearCase take a beating from the developers would be funny for you…too bad ClearCase isn’t a laughing matter. Good luck with it.
https://www.youtube.com/watch?v=vpILRv_tZy4
Josh
cvs sucks said,
May 15, 2010 @ 08:08
The example provided is a little skewed. It appears to try to make cvs appear to have less commands. But if the comparison is done at the same starting point and ending points then both utilities have the same number of commands to add an element. They are: copy file in place, identify it to the cm tool, check it in. Actually in Clearcase the last step can be incorporated into the previous one, and if number of commands is your criteria then Clearcase wins.
However the number of commands used to ci files is an extremely minor point to judge the performance of the tools on.
In cvs we have lost our source code twice in the last 2 years.
In Clearcase we have NEVER lost source code in over 10 years.
In Clearcase we can use dynamic views. These views allow nothing to be changed without the cm tool knowing about it and capturing it somewhere. The build person cannot change code and introduce bugs without the tool knowing. VERY GOOD CM procedures.
In cvs we’re forced into snapshot views. These views allow anything to be changed without the cm tool knowing about it. That means a pissed off cm person can corrupt any executable, config file or library any time they want. CVS forces us into VERY BAD CM procedures.
My experience has shown Clearcase to be extremely easy to use, reliable, and overall a better product.
lantrix said,
May 17, 2010 @ 03:32
I assume you mean my example is skewed, and not the youtube video in the previous comment.
I’m now three years into clearcase, and I would have to agree with you on this point: I now shun CVS, for reasons you mention and others. Additionally these examples were my thoughts on initial exposure to clearcase, coming from a world of BSD/CVS usage.
I’m the CM for our team, and I would think that clearcase DOES enforce good behaviour, albeit with overhead complexity. The point you made about dynamic views is correct, but the problem I face is this: we have multiple streams of ongoing development, point releases and different versions of our product. When this is the case the dynamic view(s) HEAVILY rely on a correct config spec. If you get this wrong, you can mess up your whole tree.
Another clearcase bugbear is that when I prep for a production release, the amount of work is rather large, as compared to other products I’ve used.
I should note we are not using multi-site, nor are we using UCM.
Yet – after three years, clearcase is still *overly complex*. I’m also sick of the lack of DVCS. We recently lost use of the clearcase licence server for a few days and development/merge work stopped.
To relieve my lack of DVCS pain, I’ve been using GIT for about 6 months. I’d migrate all our VOBs to it in a heartbeat. What stops that is a corporate need to have to pay licence fees and ongoing maintenance, hence we continue to use clearcase.
In fact, I’m about to do an upgrade from 2003.06.00 to 7.1, which is not good since no one will hire a dedicated clearcase Admin guy. I’m it – CM, packager, deployer (in some cases), installer, sysadmin, etc.
Thanks for the comment – it’s good to add to the discussion.
wornoutbycvs said,
January 4, 2011 @ 07:33
The group I am in used Clearcase for 10 years and I cannot remember the last time there was a problem with it. It was extremely easy to use.
We now use cvs.
In 6 months we have already had enough cvs problems to buy at least 50 Clearcase licenses. But what’s worse is the problems keep recurring. Automatic merges, special switches to cvs commands for differing behaviour, quirks in how cvs works, continue to cause the same problems over and over.
Waiting for checkouts, trying to determine what to check-in is constantly costing us time.
The group has about 10 developers and it is far cheaper for us to use Clearcase.
The licensing cost of Clearcase is trivial compared to the true cost of cvs.
CVS is being maintained here by an entire organization of knowledgeable/experienced CVS administrators. Even so the problems still occur on a regular basis.
Today I get to sit around and type on blogs because cvs is rejecting repository access. Maybe the CVS admins will have it working tomorrow.
Developer said,
March 17, 2011 @ 09:22
This group has been using cvs for a year.
It has cost us so much time and money.
‘cvs sucks’ is right….when all the accounting is done cvs costs far more than clearcase.
And cvs is a real pain to use.
RSS feed for comments on this post · TrackBack URI