The company I work for exclusively uses Clearcase. I feel it is not worth the effort to learn and use it as my project would not involve too many people(max of upto 3 people), neither would it involve fancy development flow. How do I convince my manager on using a separate source control for this when they bring up the point of "IT supported and uniform source control through out the company" against my suggestion? Or is that particular point valid and I should go with Clearcase?
Thanks...
PS: I was thinking of using Subversion.
If it's the company standard, then there should be people in the company that know it that can help you get started with it. They should be able to set up your particular IDE to work with it, and make everything as seamless as possible for you. You shouldn't have to learn anything crazy in order to use it - there should be clear instructions.
If there's not, then you're not getting the benefit of "IT supported and uniform source control through out the company" and it makes no difference what you use.
After working through this process, if an argument can be made that there's a better source control that would work better through the firm, you should make it. If it's a company standard, it shouldn't be a pain in the neck to use.
First of all, my condolences.
Is Clearcase that difficult to learn? If yes, I'd consider that a strike against it. If not, you might be better off just going with the flow and learning it.
The 3 people on your team aren't likely to be the ones that maintain the code over its software life, so that argument goes against you as well.
How big is the organization? It's easier for 3 people to learn Clearcase than for X to learn Subversion.
It would depend a lot on your boss and his/her willingness to consider alternatives.
Subversion would certainly be easy to set up and use. I'd hate to be using Clearcase myself.
But there are a lot of factors against you. Good luck.
If I were you then I'd want to use SVN because I just love it but just like anything with developement most of the time you have to go with the flow. Same as if you were extending a framework and you decided to do it your own way completely different to the rest of the framwork it would be frowned upon even if your way was much better. Also what would happen if you and your team got hit by a bus? OK SVN is easy to learn but there is still a learning curve that could slow down other people continuing your work.
You could also view this as a chance to learn a new source control system and make yourself more marketable. You could still prefer subversion, you can't be forced to change your opinion. As #Erick says if this is the company standard they should be able to support you and I'd hope you'd be able to get this factored into your timescales.
There's always the tried & true (albeit risky) approach of having your team use Subversion (how appropriate!) within itself and making the occasional show check-in to Clearcase.
Your argument against Clearcase
are
it is not worth the effort to learn
my project would not involve too many
people neither would it involve
fancy development flow.
Is it difficult to learn? If your company already using it, you will have many people to ask help from. Since your company already have clearcase, you are 80% done with clercase admin works. It will be fairly simple to create vobs, project etc.
In fact your project is small makes it more important to use standard within company. We had some fancy projects done using our standard SCM and some projects without the standard SCM. For the one which used standard SCM, when the projects is scrapped, the code is still safe with in organization. Other products, we lost people and code.
Are you using ClearCase with UCM? It is simpler than base clearcase.
As I mentioned in "Are There Any Reasons To Still Use SVN?", you can't just decide to put a new server on the side, especially for sensitive data like code sources. At some point, they need to be versioned in a central referential.
Any server for that kind of persistent and important data should be:
funded (you can't just manage a VCS on your workstation, you need an actual server)
supported (your jobs is to develop, not to manage /troubleshoot your team in term of SVN operations)
integrated (no problem on that front for SVN)
administrated (again, your job isn't to manage/monitor the SVN server)
documented (where is your SVN server?, what are the backup procedures?, is there any backup/DRP server?, ...)
For all those reasons, your manager might consider leveraging the existing infrastructure/support around the main VCS (ClearCase, condolences ;) ).
But that won't prevent you to manage a DVCS within a ClearCase snapshot view though.
I don't know Clearcase, so I can't say whether it's good or bad or how it compares to Subversion.
But the whole point of source control is that there's supposed to be a single repository where everyone knows they can go to check out their code. If one team uses Clearcase and your team uses Subversion and another uses Git and another uses CVS, etc etc, then anyone wanting to check out source code not only has to look in ten places, but they have to learn to use ten different source code control systems.
Unless you can make a case that Subversion is clearly better than Clearcase in some relevant and important way, I'd say just bite the bullet and learn Clearcase. If it was me, I'd see it as an opportunity to learn something new. After I did, maybe I'd conclude that Clearcase sucks big time and I should try to convince the powers that be to switch to something else. Or maybe I'd conclude that Clearcase was the greatest advance since the invention of USB. Either way, you now know a little more. If nothing else, it's one more bullet to put on your resume the next time you go looking for another job.
Are you working full-time for this company or is this a one-off project as a contractor?
If it's your full-time role as an employee then it's time to buy that "Clearcase for Beginners" book.
If you're looking to deliver a project quickly, then perhaps just keep your head down and use Subversion as an expedient. Ask someone to check the finished article into Clearcase as you run out of the door.
:)
Use a DVCS like Mercurial or Git and make a branch of it to keep synced up with ClearCase. Your team can do the day to day work using a better tool but your organization still has your work products accessible the usual way (which is important). Sync up with ClearCase on a regular basis, and consider adding the output of your systems DVCS log (eg hg log) to a file in the ClearCase branch, so people can see the more granular steps if needed.
DVCS systems are also usually pretty easy to set up, and often can be easily hosted on a network share or something like that. Since all developers will have a copy of the full tree it provides a certain amount of built in backup and redundancy.
This workflow is not uncommon -- gitsvn and hgsvn are both scripts people have set up to let them use those tools by themselves but sync up with folks on another repository.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Because I'm currently struggling to learn IBM Rational ClearCase, I'd like to hear your professional opinion.
I'm particularly interested in advantages/disadvantages compared to other version-control-systems like Subversion or Git.
You can find a good comparison between ClearCase and Git in my SO answer:
"What are the basic ClearCase concepts every developer should know?", illustrating some major differences (and some shortcomings of ClearCase)
File-centric operations
The most single important shortcoming of ClearCase is its old "file-centric" approach (as opposed to "repository-centric" like in SVN or Git or Perforce...)
That means each checkout or check-in is done file per file. The atomicity of operation is at file levels.
Combine that with a very verbose protocol and a network with potentially several nodes between the developer workstation and the VOB server, and you can end up with a fairly slow and inefficient file server (which ClearCase is at its core).
File-per-file operations means: slow recursive operations (like recursive checkout or recursive "add to source control", even by clearfsimport).
A fast LAN is mandatory to mitigate the side-effects of that chatty protocol.
Centralized VCS
The other aspect to take into account is its centralized aspect (even though it can be "distributed" with its multi-site replicated VOB feature)
If the network does not allow access to the VOBs, the developers can:
still work within snapshot views (but with hijacked files only)
wait for the restoration of the network if they are using dynamic views
Expensive Distributed VCS option
You can have some distributed VCS feature by replicating a Vob.
But:
you need a special kind of license to access it.
that license is expensive and add to the cost of the regular license
any vob that uses the replicated vob (admin vob, admin pvob, ...) must be replicated as well (meaning some projects not directly concerned with a distributed development will still have to pay multi-site license...)
Old and not user-friendly GUI
the GUI is very old school and impractical (mid-90's MFC look, completely synchronous GUI, meaning you have to wait for a refresh before clicking elsewhere): when browsing baselines, you cannot quickly look for one in particular.
the GUI on Unix is not exactly the same than on Windows (the latest 7.1 version is better but not there yet)
the installation process is quite complicated (although the latest Installer Manager introduced by CC7.1 is now a coherent GUI on Windows or Unix and does simplify the procedure)
the only real rich application has only been developed for CCRC (the Remote Client)
UCM inconsistencies and in coherencies
As mentioned in "How to Leverage ClearCase’s features", dynamic views are great (a way to see data through the network without having to copy them to the disk), but the main feature remain UCM: it can be a real asset if you have big project with complex workflow.
Some shortcomings on that front:
the dependencies between components is not well managed for a depth superior to one (because of the bug of "parasite baseline")
UCM still has some in coherencies and inconsistencies as documented in CM Crossroads
Limited policies with Base ClearCase
Using ClearCase without using UCM means having to define a policy to:
create branch (otherwise anyone can create any branch, and you end up with a gazillon of them, with merge workflow nightmare)
put labels (otherwise you forget to label some files, or you put a label where you were not supposed to, or you "move" (gasp) a label from one version to another: at least UCM baselines cannot be moved)
define changeset. ChangeSets only exist with UCM activities. With Base ClearCase, you are reduced to clever "cleartool find" requests...
No application rights
ClearCase right management is entirely built on system rights.
That means you need to register your user to the correct system group, which is not always easy to do when you have to enter a ticket to your IT service in order for them to make the proper registration.
Add to that an heterogeneous environment (users on Windows, and server on Unix), and you need to register your user on Unix as well as Windows! (with the same login/group name). Unless you put some sort of LDAP correspondence between the two world (like Centrify)
No advanced API
only CLI is complete ("cleartool" is the ClearCase Command Line Interface), meaning that any script (in Perl or other language) consists in parsing the output of those cleartool commands)
ClearCase Automation Library (CAL) exists, but is quite limited
Java API exists, but only for web views for the CCRC client.
View Storages not easily centralized/backed up
The View storages are the equivalent of the ".svn" of SubVersion, exept there is only one "view storage" per view instead of many .svn in all the directories of a SubVersion workspace. That is good.
What is bad is that each operations within a view (a simple "ls", checkout, checking, ...) will trigger a network request to the view_server process that manages your view server.
2 options:
declare your view storage on your workstation: great for scalability, you can have as many view as you want without taxing the LAN: all communications are directly done on your workstation. BUT if that machine dies on you, you loose your views.
declare your view storage on a centralized server: that means all view_server process will be created there and that all operations on a view by any user will have to communicate with that server. It can be done if the infrastructure is "right" (special high-speed LAN, dedicated server, constant monitoring), but in practice, your LAN will not support this mode.
The first mode means: you have to backup yourself your work in progress (private files or checked-out files)
The second mode means: your workstation can be unavailable, you can just log on another a get back your views (execpt for the private files of a snapshot view)
Side discussion about dynamic views:
To add to the "dynamic view" aspect, it has one advantage (it's dynamic) and one shortcoming (it's dynamic).
Dynamic views are great for setting a simple environment to quickly share a small development between a small team: for a small development effort, a dynamic view can help 2 or 3 developers to constantly stay in touch one with another, seeing instantly when one's commit breaks something in the other views.
For more complex development effort, the artificial "isolation" provided by snapshot view is preferable (you see changes only when you refresh - or "update" - your snapshot view)
For real divergent development effort or course, a branch is still required to achieve true code isolation (merges will be required at some point, which ClearCase handles very well, albeit slowly, file-by-file)
The point is, you can use both, for the right reasons.
Note: by small team I do not mean "small project". ClearCase is best used for large project, but if you want to use dynamic views, you need to setup up "task branches in order to isolate a small development effort per branch: that way a "small team" (a subset of your large team) can work efficiently, sharing quickly its work between its members.
If you use dynamic views on a "main" branch where everyone is doing anything, then any check-in would "kill you" as it could introduced some "build breaks" unrelated with your current development effort.
That would then be a poor usage of dynamic views, and that would forget its other usages:
additional way of accessing data, in addition of snapshot views, meaning it is a great tool to just "see" the files (you can for example use a dynamic view to tweak its config spec until you see what you want and then copy those select rules into your usual snapshot view)
a side view to make merges: you work with your snapshot view, but for merges you can use your dynamic "sister-view" ("sister" as in "same config spec"), in order to avoid having a failed merge because of checked-out files (on which you would be currently working on your snapshot view), or because of a snapshot view not completely up-to-date. Once the merge is complete, you update your regular snapshot view and resume your work.
Developing directly in a dynamic view is not always the best option since all (non-checked-out) files are read over the network.
That means the dll or jar or exe needed by your IDE would be accessed over the network, which can slow down considerably the compilation process.
Possible solutions:
one snapshot view with all in it
a snapshot view with dll or jar or exe in it (files which do not changes every five minutes: one update per day), and dynamic view with only the sources visible.
The cost is a fairly obvious disadvantage. Not just the license cost, but also the cost of a ClearCase guru's salary. Almost every company I'm aware of that uses ClearCase seems to have at least one person whose only purpose is to tame the unruly beast.
The very fact that it's complicated enough to require a full-time nanny is also worrying.
An absolute nightmare of a system. It made me wish we could go back to VSS! (Never mind any modern source-control system like Subversion or Git!)
It's slooooow.
If you use dynamic views and the network goes down you cannot access your working copy of the source. You can do nothing but sit and wait for it to be fixed.
If you use snapshot views you seem to run into conflicts and "hijacked" files all the time, so the files in your working copy are never quite the same as in the source repository.
Whenever you try a large update or deliver operation it invariably FAILS for one reason or another, requiring your ClearCase guru to spend a few hour/days figuring it out. Oh yes, you must have a dedicated, full-time ClearCase guru!
When it fails you often cannot roll back the operation, either, so you're stuck with an operation in progress and the developers are blocked.
When you look past the pretty(?) icons, the GUI is very poor - right down to things like being unable to resize windows to see full file paths!
Their support staff are quite reluctant to fix anything. Their first response is always "this is by design" and "can you work around it?" If they do ultimately provide a fix (after much arguing) it will be the most basic possible fix to the most immediate problem.
Basically, it's slow, complicated and unreliable as hell. Oh, and did I mention it's ridiculously expensive? The only way they can possibly sell it is by talking to decision-makers who have never used the product and never will! I'm quite sure that no developer in the world would ever buy it.
Atomic commits and changesets are my biggest gripes against ClearCase. Let's say you check in five files as part of a bug fix or refactoring. Then it is discovered that something got messed up and you need to revert. Good luck finding which five files they are and what version each one needs to be on. But let's take a step back. You have just finished editing those five files, and it's time to commit. The first four go through just fine. That last one requires a massive merge. The other four files are already checked in. They don't wait for you to finish your necessary changes in the last file. I sure hope that no one updated or is using a dynamic view. A continuous integration build server is going to fail too.
Sometimes we make a whole new directory full of files that need to be checked in, but we don't want to check them in until they are done. It's early and everything is still volatile, so why check things in that you might delete very soon? OK, fine so far. Now it's time to check in. You add the newly created folder to source control. Well, ClearCase isn't recursive, so only that single folder is checked in. With SVN, that folder and everything below it is added, as you choose. The developer needs to remember to add everything, otherwise, a lot of files are going to be missing.
ClearCase owns the files and folders so you cannot modify anything unless you have checked it out first. The eclipse plugin takes away a lot of the nuisance here. I can't tell you how many times I opened a file in vi to make a quick change, only to find that I had forgotten to check it out first. Checkout isn't recursive either.
Updates can be painfully slow without changesets. When you update with a snapshot view, every file updates, not just the modified files. I worked on a project with 20,000+ files. I would remote in to my work machine, start the update, then drive to work; get coffee; go to my desk while it was finishing up. That might sound like an exaggeration, but it sadly isn't.
Dynamic views are terrible unless you are in a very small team. And if that's the case, why do you even have ClearCase? I have seen countless people's views getting hosed because someone checked in files that broke the views of everyone else. You should always update and merge any conflicts on your own view. That way, the changes only affect you. With a dynamic view, you cannot merge down before pushing back up; you just commit and hope.
I know cost probably isn't a big concern, but the developers who make the money for the company would enjoy spending the $50k-$100k (depending on ClearQuest license, which is a common addition) on either fun events or new equipment (chairs, monitors, etc.). IBM recommends having staff to keep ClearCase going. Why not re-purpose those people to generate revenue for the company, instead of making sure things don't crash and burn?
Some of the reasons that I have heard for not switching:
Learning will take time and money
Learning SVN or Mercurial should take no more than a day. Only ClearCase suggests having a certain ratio of admins to developers.
Migration will be painful
This is why tools exist: cc2svn
It's not as easy with Mercurial
Security
There are no known gaping holes in SVN AFAIK, and the development team is dedicated to fixing anything that is found quickly. The Department of Defense seems OK with SVN.
No real productivity gain afterwards
It takes forever trying to track down bugs without changesets. I love being able to roll back until I can't see the bug. You can't do that in ClearCase.
Multisite
WANdisco solves that problem. It's not free though.
The only thing that ClearCase does better than the rest is branching individual files, while keeping the others on the same track as another branch.
Everything I have done in Clearcase always seems hard. Whereas, I've never had that impression with other systems(except maybe CVS on occasion).
I've used SVN, CVS, Clearcase, and Mercurial.
My experience with ClearCase was a disaster, and I will second Don's statement that it requires a resident expert-- unfortunately we had more than one. I had experience with CVS and other version control systems, I was familiar with the concepts, but I found the ClearCase documentation incomprehensible and had to ask for help several times; different experts gave me conflicting advice to the point where we actually broke cd. That is, after I issued a ClearCase command in a UNIX shell, the "cd" command failed with an error message.
The basic task of a version control system is really pretty simple. Honestly, I think that half a dozen commands should suffice, using a file scheme that plays well with others. To me ClearCase looks like the result of a marketing exec deliberately complicating the hell out of things to make the product look sophisticated and powerful. I've heard that it can be configured to behave in a simple, safe, reliable way, but again that requires the services of an expert-- out of the box it's like a motorized swiss army knife.
Everything I've experienced related in any capacity to ClearCase is inefficient, ugly, overly complex, slow, confusing, expensive and inconvenient.
It seems to attract managers and engineers that JUST HAVE GOT IT ALL WRONG.
Damn, IBM and Rational must have amazing sales guys to sell such a crappy product.
We are just migrating off CC onto Git for many of the reasons given here. I would like to add one reason to stay away from CC or any other commercial source control system.
Your vital business data is hostage to ClearCase. You can't get it out.
Your vital business data is the code, its version history and all metadata such as commit comments, who checked in and when.
All software will have a limited useful life. You should always ask yourself when you introduce a new system that swallows important business data, whether it is code, bugs, customer data or what not: How do I get my data out again? If you can't answer that question, you should not introduce that system.
When we migrated out we lost most of our history and all of our metadata. Essentially we only have history corresponding to released versions, but information about what changes were done in response to what customer requests is lost (we have that data in the customer support and bug ticket system, so it is not completely lost, but the coupling to the source code is gone).
This will be somewhere between a nuisance and a problem for us on short to medium term. In a couple of years time, it is not important anymore, but perhaps for 1-3 years it will matter.
(There are commercial tools to migrate CC to other SCM, but they were not deemed adequate to our needs, and I doubt it would have been feasible. The minimal export we did took long enough.)
The lesson learnt is: Never entrust vital business data to proprietary systems.
No atomic commits
Once you checked in files it is very hard to revert to a certain state, because atomic commits aren’t supported. When checking in multiple files, each file gets a new revision (similar to CVS) and not the check-in itself. I think this is a crucial feature, because you hardly want revert single files but complete commit actions (which should map tasks). With ClearCase you can only revert to certain states by using Labels. In practice using ClearCase Labels for each check-in is overkill and thus not done.
Crappy user interface
The GUI of ClearCase Explorer is just a big joke. Horrible in usability and ugly looking. Different and often necessary functions aren’t provided (e.g. recursively checking in worked on artifacts). Command line tool cleartool used with cygwin is much better, but still some things aren’t available like recursively adding new files/folders to source control. I have to laugh my head off if I read a 50 lines of code long script to workaround this.
High administration efforts
Administrating ClearCase beast is far from obvious or lightweight (in difference to other scm-systems like CVS, subversion or Git). Expect to put quite a few dedicated ClearCase experts to just keep it running.
Horrible performance
Nothing is worse as making your developers wait while interfacing with SCM-tool, it is like driving with hand brakes enabled. It slows down your brain and also your work. Getting fresh new files to your snapshot view takes around 30 minutes for 10K artifacts. An update (no artifacts were changed) for the same amount takes roughly 5 minutes. When experimenting a lot and jumping between different up-to-date views means a lot of waiting. It gets even worse, when you’re working on files and you want to check-in or update them. Check-out, check-in and adding to source control cycles take around 10-15 seconds which is obviously a nightmare. It gets very annoying when you’re refactoring renaming/moving types or methods (many files can be affected).
Lack of support of distributed development
Today software development is often a distributed thing (developers are spread around the world working on the same product/project). ClearCase definetely isn’t suitable for this, because it is badly suited for offline work. Doing a check-out (action before you can edit a file/folder) requires that you are network connected. Here you could use the hijack option but this is rather a workaround as a feature (you basically just unlock the file on the filesystem). If your development sites are far away from your ClearCase server the check-in/check-out latency can even increase so dramatically that it is not usable at all. There are workarounds for that like using ClearCase Multisite (scm DB replica technology), but you have to pay extra for it and is not trivial to adminstrate.
Git as alternative
Though being a big fan+supporter of Open Source I am still willing to pay money for good software. But looking at IBM-monster ClearCase I wouldn’t invest my money here, it has all these discussed shortcomings, and further more IBM doesn’t seem to invest money to improve their product significantly. Recently I had a look a Git scm which looks very good, especially for its branching+merging features, where ClearCase has its major strengths.
This information taken from http://www.aldana-online.de/2009/03/19/reasons-why-you-should-stay-away-from-clearcase/
Possibly the worst software ever made. I will not work for any firm that uses rational anything. Aside from CC completely crashing and restarting my workstation frequently on dynamic builds. What happens when you are pushing something to source control and CC does what it does best, crash? Is your code then put in lost+found, backed up somewhere maybe? No, it is gone forever. So if you are ever in the god-awful situation of using this giant piece of expensive software, keep duplicates of everything. Good job Rational / IBM. Way to capture the most important part of source control, reliability. Die slow.
Downsides of ClearCase - an addition to the most in-depth post here.
The merge tool is not worthwhile. It barely helps you, remembers no decisions you made, its just a glorified diff.
The merge tool has to check out directories to even CHECK if they need a merge. Its a bit insane.
I use BitKeeper at work (let's assume Git), and merging two repositories even if there are conflicts is so trivial and user friendly even with command line, while ClearCase having tons of GUI tools is a long and laborious process which is also extremely error prone.
All GUI tools require a ton of latency. Even seeing what can be done on a file requires a high speed connection. So right-clicking in the ClearCase tool on a file working from home could take a minute or two having high speed internet because of the extreme amount of networking requirements.
Someone can completely mess up the repository or check-ins if they make their view spec different than the team. Which is quite insane that nobody can just check out some branch; they need the appropriate view spec which will incidentally give them the right stuff. The whole concept can be nice and flexible but 99% of the time it just causes lots of pain. Did I mention you can't email your spec via Microsoft Outlook since CC tools don't accept UTF-8 so you can't copy-paste it?
I have absolutely nothing nice to say about CC. I used it for 2 years at 2 companies and dropped it in a heartbeat feeling happy the entire time. It is also impossible to just experiment with at home with your own projects, so you will still learn SVN or Git at home, and be forced to go through ClearCase pains at work. Nobody I know has ever used CC voluntarily. They only use it because some manager at work decided CC is the path to salvation and forced everyone to migrate to it. In fact my last company migrated from CVS to ClearCase, and after one year from ClearCase to SVN. It was that hated.
ClearCase is not just one thing that makes you say no. It's like living in a house infested with ants. Each ant is just a minor inconvenience at best, but the infestation will drive you mad.
I'm trying to consolidate a few comments into an actual post here. I'm not really here to persuade you that one is better than the other, except by way of making a few points:
If you're comparing git and ClearCase, I respectfully submit that you need to better define your needs - if you are considering ClearCase for a "good" reason, the git probably isn't even in the equation - it's far too new to trust for enterprise-level source control, imo.
ClearCase introduces a lot of concepts into the version control space that other systems don't have, so it can be pretty daunting and confusing. Especially if the only experience you have is reading the documentation, as appears to be the case for a few people here.
ClearCase is definitely not well suited to huge code bases supported by developers who are not on a LAN with a VOB server. You can have many replicated (multi-site) VOB servers to get them close to remote developers, but this isn't necessarily practical if those remote sites are just a single developer.
Do you want file versioning or repository versioning? This is a pretty important question, and one that will necessarily filter out an entire set of tools, making your job easier. Repository versioning has a lot of advantages (and it's not "new", like some posters claimed - commercial tools like Perforce have been around for more than a dozen years, and there may have been tools that did repository versioning even before Perforce), but it isn't a panacea.
With a sufficiently large installation of any source control system, you're going to need help. When considering tools, you need to consider how easy it will be to find people to help you (either job applicants who have experience, or consultants who will be there at a moments' notice to address any issues). There's no such thing as a maintenance-free SCM system, and assuming you have one will get you into more trouble than picking one that requires "too much" administration.
Don't pay too much attention to people who talk about how bad "dynamic views" are - bad SCM policies are bad, regardless of the tool you're using. Your configuration management policies and practices have to be separate from your choice of tool - no tool will stop people from smashing all over your codebase if you don't define sensible branching and merging policies. If someone suggests that having developers directly commit onto /main is ever a sensible idea, you might want to walk away from that conversation.
ClearCase is a fine tool, but it is a complicated tool. There is no getting around this - it does not have an "easy install" mode. :-) From a technical standpoint, there's nothing that git or SVN can do that ClearCase cannot (although often the terminology is different, since Open Source projects tend to just invent new taxonomy where there already existed one), but some things are definitely easier/harder for a given system, depending on their design. ClearCase "snapshot" views are basically the same thing you would have if you checked out a repository from SVN or CVS - it's a local copy of the source code on your machine, with pointers back into the central server for tools to query version history, etc. You can work with these views without any network connection to the ClearCase server at all once they have been created, and you can "recycle" them to avoid downloading your entire repository again when you want to move to work on another branch, for example. "Dynamic Views" are basically a ClearCase invention, and the standard operating mode for a LAN. They appear the same as checking out an SVN repository, but they don't actually copy any files until you make changes. In this way the view is available immediately, but it obviously cannot be worked with if the main clearcase server is unavailable, and is unpleasant to work with over a high-latency connection. They also have the convenience of being able to be mounted as a network drive on any machine with access to the server on which they were created, so if your windows workstation dies, you can just log onto another one, mount your view, and get back to work, since all the files are stored either in the VOB server (for files you haven't modified on this branch), or the view_server (for files you have created or modified just in this view).
Also, and this deserves its' own paragraph....clearmerge is nearly worth the price of admission alone. It's hands down the best merge tool that I've ever used in my life. I firmly believe a lot of bad practice in SCM has developed because of a lack of high-quality merge tools, so CVS users never learned to use branches properly and this fear of branching has propagated to the current day for no particularly good reason.
Ok, all that being said, if you're looking for reasons not to use ClearCase, they're not hard to find, although I think that's the wrong way to go about it. Really you should need to come up with good reasons TO use ClearCase, not reasons for NOT using ClearCase. You should come into any SCM situation assuming that ClearCase is too much tool or too complicated a tool for the job, and then see if you have some situation that encourages you to use it anyhow. Having IBM or Rational logos is not a good reason.. :-)
I would not even consider ClearCase unless you could say yes to all the following statements:
You do now, or will eventually have, more than 50 developers working on the same codebase.
Most of those developers are centrally located, or have high-throughput low-latency connections to a central location.
You have a set of SCM policies and can identify how to use ClearCase to enforce those policies (really you should consider this for any tool)
Money really is no object
My experience is mostly limited by CC, CVS and SVN. In principle, CC is technologically capable, enterprise ready and comparable by features with any modern VCS. But it has several flaws that make it unusable in any people-oriented environment. For process oriented environments it is probably more appropriate, though I doubt that such environments are appropriate by themselves. Maybe, in military, cosmic or medical software, I don't know. Anyway, I believe that even for these domains there are appropriate and still more friendly tools.
Beside being technically capable VCS, CC has several distinctive advantages:
Dynamic views
Nice version tree
Triggers
Good merge versioning, including renames
In my opinion, their use is limited excepting last one; and they don't compensate flaws. Dynamic view nice in theory, but not always available in practice. Version tree has much less use in other VCS, while necessary in CC because of proliferation of branches (see 6). Triggers, as I know, very detailed and capable, but I think that for most practical tasks SVN hooks are good enough. And now about disadvantages that mostly concerns usability:
CC totally fails in sense of usability for main user group: for developers. And that is the main reason why I think that it should never be used in any environment, be it enterprise or not. Even if it were free, it would nevertheless suck your company's money by wasting time of your developers and frustrating them. This point is composed from:
"Check out-Check In" with strict locking approach - it is counter-productive, refactoring unfriendly, and dangerous in repository organizations with single development branch for multiple developers. Meanwhile, the advantages of strict locking are negligible.
Poor performance and high load
It effectively cannot be used remotely without multi-site (due to 2). Multisite is expensive too. ClearCase Remote client is very limited. It don't even have cleartool (before version 7.1), leaving alone dynamic views.
It can hardly be used offline. Dynamic views are just not work. Snapshot views are effectively read only, because you cannot check out without access to repository (see 1). Hijack is poor option which in fact means that CC gives up any responsibility for hijacked file. And CC cannot show you difference with previous revision when offline. SVN is able to show difference with previous revision even being offline.
Overly complicated model, especially with UCM: VOBs, PVOBs, Projects, streams, branches, views, deliver, update, load, restore, rebase, merge, baseline, check in, check out. I think that half of this concepts are just superfluous and doesn't add value, while increasing both technical and conceptual complexity. Few developers understand even basic stuff about CC.
Proliferation of branches. For example, repository often organized with stream per developer (due to 1). It just has no sense in SVN or most other VCSs.
No repository wide revisions. Well, there are such revisions as understand, they called baselines. But when I see some file revision and want to get repository snapshot at the moment of that file revision, I will get some problems. I will need to do black magic with config spec to create a snapshot view, or find somehow through dynamic view if it is available.
Crappy user GUI. Version tree, even being nice, has mediocre usability. Merge tool is just a pity. Other "features": not resizeable windows, absence of incremental search in some places, mouse-centric interface, look and feel in 1995 style, strange work flow distributed between Client and Project Explorer etc.
CC provokes rare and vast check ins. You all know, that check ins must be small and frequent. But developers usually refrains from additional interactions with CC, hijack files and work in local VCS or even without VCS at all (which is more often, unfortunately). And then, after two weeks of development they begin commit comlex feature that adds 20 files and affects another 20 files. It lasts for a day or two, because they hijacked files and now need to perform manual merge with all new changes from repo and resolve all conflicts and discrepancies. During that process, code lies not compilable, because several files successfully got checked in and others do not. And after that it still lies not compilable because they forgot to add another 2 files to CC.
It is very expensive
It is very complex in terms of infrastructure and requires dedicated administrators
ClearCase seems extremely powerful, from the outside. But really, it's just that the number of commands and options you need to use for basic workflow is so high that these get hidden behind a few aliases or scripts, and you end up with something less powerful than CVS, with the usability of Visual Source Safe. And any time you want to do something a little more complicated than your scripts allow, you get a sick feeling in your stomach.
Compare this with Git, which seems complicated from the outside, but after a week working with it you feel completely in control. The repository model is simple to understand, and incredibly powerful. Because it's easy to get at the nuts and bolts, it's actually enjoyable to dig below the surface of your daily workflow.
For example, figuring out a trivial task such as how to just view a non-HEAD version of a file in a snapshot view took me a couple of hours and what I ended up with was a complete hack. Not the enjoyable sort of hack either.
But in Git, figuring out a seemingly complicated task such as how to interactively commit only some changes, (and leave the rest for later) was great fun, and all the time I have the feeling that the VCS is allowing me to organise code and history in a way that suits me, rather than history being an accident of how we used the VCS. "Git means never having to say 'you should have'".
At my work, I use Git for all sorts of lightweight tasks, even within ClearCase. For instance, I do TDD, and I commit to Git whenever a bunch of tests pass and I'm about to refactor. When the task's eventually done, I check in to ClearCase, and Git helps me review exactly what I'm changing. Just try to get ClearCase to produce a diff across a couple of files - it can't! Use Google to find out the various hacks people have tried to work around this. This is something version control should do out of the box, and it should be easy! CVS has had this for decades!
Nightmare to administer in secure environments
Outdated technology
Non-intuitive GUI
Expensive
Resource monster
Sellout to Microsoft
In my opinion? Only reason to have it? If you are religiously following RUP.
The support is terrible. We've had tickets open for years. Our eclipse guru actually fixed a bug in their eclipse plugin locally in about 30 minutes by disassembling the java file. But the ticket still hasn't got past level one support. Every so often they either try to sneakily close it or ping it back to us 'to try on the latest version' (even though we sent them a reproduction recipe which they could try for themselves.).
Do not touch with a barge pole.
Performance.
ClearCase is powerful, stable (IF properly maintained and supervised) but it's slow.
Geological sometimes.
Dynamic views views lead to horrible build times, snapshot views can take ages to update (lunch break for large projects) or checkout (go home for the day).
Clearcase is so annoying it actually drives people to write poetry about it:
http://digital-compulsion.blogspot.com/2007/01/poetic-pathetic-version-control.html
http://grahamis.com/blog/2007/01/24/if-it-was-free-no-one-would-download-it/
The developers will spend 1/2 their time figuring out clearcase before doing any work and once they've figured it out they'll install git locally and only push to the clearcase repo as needed.
You'll have to employ a dedicated Clearcase admin.
I would suggest SVN for toolset and Git for scaling/workflow. I'd also suggest avoiding CC where possible. (Not counting money, the fact it is such a pain to use that is requires a full time admin is a total joke)
I recently had to wrangle with a similar situation. Maybe you can learn from my story.
The team I was newly assigned to was using a heavyweight tool in an convoluted, error-prone manner. I first attempted to sell them on my tools and processes of choice. This attempt failed miserably. I was flabbergasted that they would pick such a burdensome environment over one that was both easier and more effective. Turns out that they wanted to be disciplined, and using a painful process felt disciplined to them. It sounds wierd, but it's true. They had a lot of other misconceptions too. After I figured out what they were after, we actually stuck with the same tool suite (Serena), but massively changed how it was configured.
My advice to you is to figure out what matters to your team. Ripping on ClearCase won't get you anywhere unless you speak to their interests. Also, find out why they don't want to use alternatives. Basically do a little requirements gathering and fit your tool choices to your needs. Depending on your options, who knows, Clear Case may end up being the best option after all.
I'm not totally against ClearCase ( it does have it's advantages ), but to list out the disadvantages:
License Limitations - I can't easily work from home, because I don't have access to the license server. Even with a snapshot view on my laptop I have to play tricks because I can't get a license. There is a special remote client, but adds tons of its own limitations to the mix
License Limitations again - Only so many seats to go around, and then no one can use it.
Unix tools out of date - ClearCase seems to run best on Unix systems, but the GUI tools suck there. Windows/Unix integration of ClearCase introduces all sorts of its own pains.
The biggest downfall for me is both the performance (especially if your VOB is multisite or offsite), and potentially lengthy downtimes.
If you're like me and work in a relatively small office as part of a large company (with no onsite IT), Clearcase servers going down can cost you the better part of a workday in non-productivity as well as getting the right people to get it fixed.
Bottom line, use it only if you really need it for what you are doing and make sure you have a beefy IT budget to maintain it.
ClearCase is perfectly usable if your willing to also use another version control system on top of it! personally I find using mercurial ontop of CC to work quite well.
no atomic checkins
As of the new version of version 7.1 CC provides atomic checkin as functionality IF you like that. Personally I would really not want it but apparently some people see that as "an essential feature". I NEVER would want one big bulk in one go as a sort of massive version. Then again... if you want it just turn it on.
so... no longer an argument.
We used UCM ClearCase integrated with ClearQuest (DR Tracking/change request system) for the last 4 years with more than 50 developers. We have over 50 UCM projects over thousand of streams that handled over 35K DRs and change requests. During this period we have officially made over 600 integration deliveries and while having up to 6 concurrent development and release efforts.
I am the main CM/ClearCase guy with a backup who is able to perform the regular delivery/merge and integration builds. The network and servers are supported by the IT team. All I can say is we have had virtually no problems coming from the CM side of this huge development effort and were never a show stopper. Our developers where trained with just the basic stuff and a simple steps were given to them whenever a new project (branch) was created at the request from the project management.
Too many developer complained about ClearCase because they lack the proper CM/IT/ClearCase/Process/Management support. Developers should focus on development not SCM or be a tool specialist. For a large software development, at least 5-7% of the budget should be spent on CM and tool support.
Running a JDK from a VOB in Linux.
Try it, you need to play with the LD_PRELOAD variable (I know!)
the point of "it needs a dedicated person" and "it is complicated" etc....
The core issue here with finding this a problem is that you have to define if you want to have configuration management performed in your organization (which is NOT version management). Configuration Management is like Project Management: even without a tool you still can do project managment and without a tool you can do Configuration Management. Lots of people have a hard time understanding this and lots of people think Configuration Management is equal to a tool which versions sources of software or something...... (therefore comparisons with subversions or other VERSION management systems)
ClearCase is a solution that is build for usage in a Configuration Management environment ERGO: there is a configuration manager (just like "there is a project manager").
So... if in your perception that dedicated person is there to manage a tool I think there is something very wrong. In my perception there is a dedicated person who does configuration management who from an end-user perpective only shows up when there is a problem with the tool but regards this as only 1% of his job.
So what you need to do (like in any other software project) go back to your requirements and put a list of requirements together on what your organisation wants with configuration management. AND YES like in any other software project you will have users (like e.g. developers) who totally not agree with other users (like e.g. management) on certain requirements. There lies the key imho on some reactions I read here.
And IMHO if you have the organization list of requirements AND a configuration manager in the mix.... the choice is pretty clear (see also the forum on www.cmcrossroads.com)
ClearCase is not a tool only for end-users entering their sources under version control like subversion or git. That is only 1% of why a configuration manager really wants a mature configuration management tool.
And... I think the choice of a CM system should never lay with developers equal to choosing the right project management tool or the right CRM system. Developers are end-users of a certain part of the functionality of the tool.
I will be maybe alone here, but ClearCase is not that bad as everyone says. It can handle huge repositeories. Dynamic view are pretty cool and powerful feature too. It is reliable, can be customized by adding triggers and constraints on a pef file basis, permissions, etc.
Unfortunatelly, it comes with a price, big price. It is costly, and to operate properly needs to be properly configured and maintained by dedicated IT team. It makes it really good for BigCo, but not so wise choice for SmallFirm.
I'm a big fan of DVCS and git, but can understand why would BigCo choose ClearCase over SVN and Git. What I can't understand why would anyone choose SVN over Git ;>
Dynamic Views. Must admire a fully functional translucent file system.
One big benefit is that the Intellectual Property is always in the corporate network. A laptop can be lost/stolen and no source code in jeopardy.
Another is the instant access to source code and changed files, no time is ever spent downloading anything.
It serves well for the purpose it has.
I've been programming for 10+ years now for the same employer and only source code control we've ever used is VSS. (Sorry - That's what they had when I started). There's only ever been a few of us; two right now and we usually work alone, so VSS has worked ok for us. So, I have two questions: 1) Should we switch to something else like subversion, git, TFS, etc what exactly and why (please)? 2) Am I beyond all hope and destined to eternal damnation because VSS has corrupted me (as Jeff says) ?
Wow - thanks for all the great responses!
It sounds like I should clearify a few things. We are a MS shop (Gold parntner) and we mostly do VB, ASP.NET, SQL Server, sharepoint & Biztalk work. I have CS degree so I've done x86 assembly C, C++ on DEC Unix and Slackware Linux in a "time out of mind" ...
My concern with VSS is that now I'm working over a VPN a lot more and VSS's performance sux and I'm afraid that our 10+ y/o version 5 VSS database is going to get hoosed...
There's the LAN service that's supposed to speed things up, but Ive never used it and I'm not sure it helps with corruption - has anyone used the VSS LAN service? (new with VSS 2005)
I'd probably go with Subversion, if I were you. I'm a total Git fanatic at this point, but Subversion certainly has some advantages:
simplicity
abundance of interoperable tools
active and supportive community
portable
Has really nice Windows shell integration
integrates with visual studio (I think - but surely through a third party)
Git has many, many other advantages, but the above tend to be the ones people care about when asking general questions like the above.
Edit: the company I now work for is using VisualSVN server, which is free. It makes setting up a Subversion repository on a Windows server stupid simple, and on the client we're using TortoiseSVN (for shell integration) and AnkhSVN for Visual Studio support. It's quite good, and should be fairly easy for even VSS users to pick up.
Latter-day Edit: So....nearly eight years later, I would never recommend Subversion to anyone for any reason. I don't really recant, per se, because I think my advice was valid at the time. However, in 2016, Subversion retains almost none of the advantages it used to have over Git. The tooling for Git is superior to (and much more diverse) what it once was, and in particular, there's GitHub and other good Git hosting providers (BitBucket, Beanstalk, Visual Studio Online, just off the top of my head). Visual Studio now has Git support out-of-the-box, and it's actually pretty good. There are even PowerShell modules to give a more native Windows experience to denizens of the console. Git is even easier to set up and use than Subversion and doesn't require a server component. Git has become as ubiquitous as any single tool can be, and you really would only be cheating yourself to not use it (unless you just really want to use something not-Git). Don't misunderstand - this isn't me hating on Subversion, but rather me recognizing that it's a tool from another time, rather like a straight razor for shaving.
Looks like SubVersion is the winner here. I'd do yourself a favor and use VisualSVN Server. It's free and will save you a bunch of installation headaches.
If you're used to the way VSS works, check out (no pun intended) Sourcegear's vault. It's an excellent way to migrate away from VSS as it comes with IDE integration and supports check out / check in, but when you're ready and feel comfortable you can also move to the edit update commit style of programming found in SVN.
It's free for single developers, runs on IIS and is built on .net so it should be a fairly familiar stack for you to switch to.
Whatever you do, don't change for the sake of changing.
If it's working for you and you're not having problems with it, I don't see any reason to switch.
For what it's worth, Perforce is a potential option if you truly stick to 1 or 2 users. Current perforce docs says you have have 2 users and 5 clients without having to start purchasing licenses.
You might have reasons to switch to perforce depending on your workflow and if you have need of branching the way perforce does it. Not being overly familar with some the other products mentioned here, I can't tell you how perforce compares in the feature department for things like branching, etc.
It is speedy, and it's been rock solid for us (300+ developers on a 10+ year old codebase). We store several T of info and it's been quite responsive. With a small number of users, I doubt that you'd experience many performance troubles assuming you had good hardware for your server.
Having used VSS before, I believe that you can get so many benefits out of a better SCM system that switching should be considered regardless of whether you have corruption or not. Branching alone might be worth it for you. A true client/server model, better interfaces (programmatically and command line) are a couple of other things that could really help just improve your workflow and help somewhat with productivity.
In summary, my view of Perforce is:
It's fast and quite reliable
Plenty of cross platform client tools (windows, unix, mac, etc)
it's free for 2 users and 5 clients
Integrates into developer studio (and other tools)
Has a powerful branching system (that might or might not be right for you).
Has several scriptable interfaces (python, perl, ruby, C++)
Certainly YMMV -- I only offer this alternative up as something that might be worthwhile looking into.
I've recently started using Mercurial for some of my work. It's a distributed system like Git but seems easier to use and seems far better supported on Windows, the latter of which was crucial for me.
With distributed source code control every user has a complete local copy of the repository. If you're the only person working on a project, as you say you often are, this can simplify things a lot since you just create your own repository and do all your commits etc. locally. If you want to bring on other developers later you can just push the full contents of your repository - current versions and all history - to another system, either on a shared server or directly on to another users' workstation.
If you're working only with a local repository remember you'll need a also backup solution as there isn't a copy of all your code on a shared server.
I think that Mercurial has lots of other advantages over Subversion, but it does have a big downside which has already been mentioned as a plus point of Subversion: there a lots of third party tools and integrations for Subversion. As Mercurial hasn't been around nearly as ong the choice is much less. On Windows it seems that you either have to use the command line (my choice) or the TortoiseHg Windows Explorer integration.
VSS is horrible. I may be channelling Spolsky (not sure if he's said this), but using VSS is actually worse than not using source control at all. Despite its name, it isn't safe. It creates the illusion of safety without providing it.
Without VSS, you'd probably be making regular backups of your code. With VSS, you'll think, "Mehh, it's already under source control. Why bother backing up?" Great until it corrupts your entire codebase and you lose everything. (This, incidentally, happened at a company I worked at.)
Get rid of VSS as soon as you can and switch to a real source control solution.
Don't worry about VSS corrupting you, worry about VSS corrupting your data. It does not have a good track record in that department.
Back up frequently if you do not switch to a different version control system. Backups should be happening daily even with other SCMs, but it's doubly important with VSS.
I like using Subversion for my personal projects. I could go down the list of features and pretend like it brings a lot to the table that other source control systems don't, but there's tons of good ones out there and the right choices is really a matter of style. If you check in after each small change (i.e. one checkin per function change), then many people can work on the same source file with very low risk of merge conflicts in practically anything but VSS (I haven't used VSS in years but from what I remember only one person at a time can work on a file.) If this isn't ever going to happen to you, I feel like the best course of action is to use what you know. VSS is better than no source control at all, but it feels restrictive to me these days.
I don't think you're beyond hope because you're asking if it would be better to switch; you're beyond hope when the answer is obvious and you ignore the evidence.
Even if you don't change source control systems, you ought to pick one like SVN or git and spend a few weeks reading about it and making a small project using it; it always helps to sharpen the saw.
I don't agree with the people that say that if you don't have problems you'd better not switch.
I think that SCM is some of the disciplines a good developer should know well, and frankly, even if you master VSS you are just experimenting a small fraction of the advantages a good SCM tool and SCM strategy can do for you and for your team.
Obviously evaluate and test the alternatives first in a non-production environment.
At work we use subversion with TortoiseSVN - works very nicely but it is philosophically different to VSS (not really a problem if there's just you but worth being aware of). I really like the fact that the whole repository has a revision number.
Given a free choice I'd've probably gone with vault but at the time I had zero budget.
I'm looking at things for personal use. There are reasons to use subversion and reasons to use something completely different. The alternatives I'm considering are Vault (as before, free for single use) and Bazaar. GIT I've had to dismiss as I am, unashamedly, a Windows person and right now GIT just isn't.
The distributed nature of GIT and the option of private/temporary checkins (assuming I've understood what I've read) is attractive - hence my looking at Bazaar.
Update: I did some more digging and playing and I actually went for Mercurial for personal use, integrated install with TortoiseHg makes things very simple and it seems to be well regarded. I'm still trying to work out how to force an automagic mirror of commits to a server and there appear to be some minor limitations to the ignore function but its doing the job nicely so far...
Murph
I'd say stick with what works for you. Unless you are having issues with VSS, why switch? Subversion is swell, though a little sticky to begin using it. TFS is far better than VSS, though it is fairly expensive for such a small team. I have not used git so I can't really speak to it.
i used vss for years until switching to svn about two years ago. my biggest complaints about vss were the poor network performance (that problem may be solved now) and the pessimistic locking of files. svn solved both those, is easy to set up (i use collabnet server and tortoisesvn client, although there are two good visual studio plugins: visualsvn - commercial, and ankhsvn - open source), easy to use and administer, and well documented.
it's tempting to say "if it's not broken then don't fix it" but you would get to learn a more modern source control tool and, perhaps more importantly, new ways of using source control (e.g. more frequent branching and merging) that the new tool would support.
If you only have 2 people, and you mostly work independantly, git is going to give you a lot more flexibility, power, and be far and away the fastest to work with.
It is however a pain in the backside to use. Using VSS you're obviously programming for windows - if you're doing Win32 API stuff in C then git will be a learning curve but will be quite interesting.
If the depths of your knowledge however only extend to ASP and Visual Basic, just use subversion. Walk before you can run.
** I'm not trying to say if you only know VB you're dumb or anything like that, but that git can be very finicky and picky to use (if you've used the WinAPI in C you know all about picky and finicky), and you may want a more gradual introduction to SCM than git provides
If you are a one man show and strictly a Microsoft shop, then SourceGear Vault is definitely a prime candidate for switching too.
Features:
Free for Single User, great for you
It uses SQL Server for it's backend, therefore data reliability is huge
It has atomic check-ins, all files checked-in at the same time are arranged in a group and are called a changeset.
VisualStudio integration.
Has a tool for importing from SourceSafe, therefore you can keep your history
The client communicates with the server over HTTP, therefore accessing the source outside the office remotely can be setup very easily and performs well, because they only transfer the deltas of the changes being submitted and received. You can use SSL to secure the connection.
I would definately consider this as an option.
If you want a full Life Cycle in one package then you probably want want to look at Visual Studio Team System. It does require a server, but you can get a "Action Pack" from MS that includes all the licencies that you need for "Team Foundation Server Workgroup Edition" from the Partner centre.
With this you will get Bug, Risk and Issue tracking as well as many other features :)
Source Control
Work Item Tracking (Requirements, Bugs, Issues, Risks and Tasks)
Reporting on your project data (Work Item Tracking, Build, Checkins and more in one qube)
Code Analysis
Unit Testing
Load Testing
Performance Analysis
Automated Build