Perl Training Logo: Praying Mantis
Clear Case vs Subversion

The original version of this comparison was written by Idan Miller while evaluating Clear Case vs. Subversion for his workplace.
It was translated to English and slightly changed by Gabor Szabo.
Original was based on Subversion 1.2 and Clear Case version 2003.0610
Our organization has been using Subversion for more than 6 months now.
This copy was last update on 2nd July 2005, comments from both the Subversion and the Clear Case community are welcome
To see a discussion about this and other related issues visit the Subvesion compared to XYZ page.

Issue\Tool:Base Clear CaseUCMSubversion
Stability: Usually stable, No loss of data. Sometimes, in unusual operations (e.g. deleting parent directory) some of the files might disappear and show up under Lost & Found. During the period we used it we encountered sever stability issues. Information that turned to be Corrupted, errors during Rebase and Deliver. All kinds of problems that needed restart of the server. The product is known to be stable both under Apache and while using svnserve. We have not encountered problems of stability. Other parts of the Organization are already using Subversion (one using svnserve and the other using Apache) and they have not encountered stability problems.
Working off-line: Allows working off-line except for Checkin and checkout. Allows working off-line when Snapshot View is defined though there is no need for this when working in Stream for each developer. Allows off-line work except Commits and Updates. Can be used with SVK (a free 3rd party tool) that allows Checkouts, Updates and Commits even when off-line. Keeps the changes on the local machine and can be synchronized when the local machine is connected to the Subversion server again.
Recovery from failure, Atomic Commit No support of atomic commit. Each file is checked in separately. No support of atomic commit. Each file is checked in separately. It is possible to Rollback partially successful Checkout operations but one needs to know which files to Rollback. Supports Atomic Commit. Either every (requested) file is committed or nothing. This makes sure no partial information will be committed.
Performance CC is known to be create heavy load on the server and provide low performance UCM adds additional load and reduces the performance of Deliver/Rebase Light weight sever with low overhead in the operations. Branching is nearly immediate. Update and Commit sends only the diffs from/to the server.
Server Administration Needs ongoing administrative attention: The local experience shows that every day there is a small problem that needs about 1 hour work and once every two weeks there is a problem that needs more than one hour of work. Needs further administration mainly because of problems we encountered in Rebase/Deliver Very low administrative requirements. Other parts of our organization that already use it did not need to touch the server in half a year.
Backup There are ready made backup scripts but need to shut down the server for full backup. There is NO ready made backup script, the administrator has to prepare it. Have to shut down server for backup. There are available backup scripts. No need to shut down the server for backup. One can keep working during backup.
Operating System Support Windows, Linux, Unix Windows, Linux, Unix Windows, Linux, Unix. Client supports additional OSes.
Integration with Development tools Good integration with Visual Studio .NET and with Windows Explorer Acceptable integration with Visual Studio .NET although sometimes there are problems that can cause a break in the work. Good integration with Windows Explorer Integration with Visual Studio .NET (AnkhSVN)
Integration with Bug tracking systems There is no Activities concept hence no integration with Clear Quest. Good integration with Clear Quest using Activities: When one opens a bug in Clear Quest and when associated with a user an Activity opens. Changes in Clear Case can be connected to this Activity and by that to the given bug. Good integration exists with tools like Trac or Bugzilla When committing a change in Subversion it is possible to also change the status of a bug to fixed so the commit becomes related to the bug. This both connects the bug with its fixes and changes the status of the bug to fixed eliminating one step in the work flow.
Integration with Microsoft Office applications Good integration with MS Office applications Good integration with MS Office applications No integration with MS Office. It is possible to connect to the WebDAV interface of Subversion that will execute a Commit on every save operation
Reserved Checkouts It is possible to make a Reserved Checkout and then others cannot Checkout before the this users Checks in. Reserved Checkout lock the files in the Stream only It is possible to do Reversed Checkout
Optimistic checkout methodology For editing a file it has to be first Checked out after creating a View. (an overhead) Every Checkout can be either Reserved or Unreserved. If a file changed in the repository and in the workspace as well the system does not require the user to update his workspace before committing a the change (by executing Update). This will cause a merge on Checkin. This might be problematic as the merged code was not seen by a human and never tested. Like in Base CC but when checking in to a View it only changes its own Stream. Executing Rebase/Deliver as usual. (This enables branching) This is the normal default way of using Subversion. If a file is changed both in the repository and in the local workspace Subversion requires the user first to update the local copy (by issuing an update command) and making sure the files are merged. (Either automatically or if that is not possible then manually) This gives an opportunity to the user to see the merged code and test it before committing the change to the repository.
File merging capability Merge is done based on the type of the file. Often there is Trivial Merge While the merging capability of CC is very good and fits the type of the file still occasionally the Trivial Merge can actually ruin files. The main problem is that these issues come up only at the time of installation and fixing needs lots of work. This happened to us once when all the installation scripts were corrupted. It is impossible to use external merge tool. (YY: I use Araxis Merge with it) The same as in Base CC Very simple merge capability not specialized for the type of the file. It is possible to add external merge tools. Trivial Merge is done only when the changes were in distant areas of the file. This means more often will the developer be required to do manual merge. On the other hand the chances of broken files caused by Trivial Merge are lower.
History It is possible to see the history based on Checkouts. In addition to the checkouts it is possible to see history of Deliver and Rebase. It is possible to see the history of checkouts. There is no history of merges between branches. The recommendation until this feature is implemented is to include a comment in the log message of each commit naming the branches that were merged.
Branch/stream merging capability It is possible to create branches and then merge them. It is possible to create branches by creating a new Stream. It is possible to merge to another Streams by using Deliver of Activities. It is possible to create branches. (Just a simple copy of the directory tree) and then to merge between directory trees.
Network security It is required to open all the ports because CC allocates ports dynamically. Hence we could not put a CC server in the server farm as internal system security group did not allow opening the ports
It is required to open Windows Shares on the client machine which is unacceptable by the internal system security group. The share does not need to be for Everyone that makes this acceptable.
Authentication is based on Active Directory, it is possible to define that only users in one of the Groups can access CC.
Same as in Base CC When using the Apache server for networking it is enough to open the standard port 80 (or the standard port 443 for https)
No special need.
When using the Apache server, all the Simple Authentication tools of Apache are usable. It is also possible to work via ssh if using the svnserve instead of the Apache server.
User administration Connecting to Active Directory. Every user who needs access to CC have to be in one of the Groups Same as in CC When using Apache, one can use any of the authentication techniques of Apache. When using with svnserve the users and the encrypted passwords can be in a plain file.
Access rights Per File or per directory based on user or group Same as Base CC If using Apache then it is possible to set access rights per directory based on user or group
Remote access without a client It is possible to get read access via Web. Same as Base CC It is possible to get read access via Web when using Apache.
Clients There is an add-on to Windows Explorer, and an application called CC Explorer. There is an add-on to Visual Studio Same as Base CC There is an add-on to Windows Explorer (TortoiseSVN), There is an application called RapidSVN, There is an add-on to Visual Studio (Ankh)
Localization (Hebrew) Support Full support of Hebrew: Filenames and Checkin comments Same as Base CC Full support of Hebrew: Filenames, Checkin comments and Property values
Comparing versions (diff) It is possible to compare text files. The comparison is based on the type of the file. It is possible to use 3rd party diff tool. Same as Base CC It is possible to compare text files. No special comparison based on the type of the file. It is possible to use 3rd party diff tool.
Capability to fetch older version with returning It is possible to change the View to point to an earlier version based on numbers. One has to create a baseline on the version and Deliver it to a new Stream (administrative operation) There is a tool called Baseline Composite that helps retrieving an old version It is possible to check-out a version based on a version number or a date. It is also possible to look at old versions using a Web-based add-on tool (WebCVS)
Capability to go back to earlier version It is possible to go back to an earlier version using the version tree It is also possible to set a full stream back to Baseline. It is possible to get back any earlier version based on its number. The numbers can be seen in a version tree like way (e.g. in TortoiseSVN)
User interface Good interface bot in Windows Explorer and CC Explorer The interface of Deliver/Rebase (Project Explorer) is not that good but acceptable Deep integration with Windows Explorer marking the files with special icons by TortoiseSVN. Multi platform client called RapidSVN
(Local) Support Support by IBM but IBM does not recommend this solution. Support by IBM. In reality there is a contact person in another part of our organization for problems. He is not always available and in our part of the organization there is not enough knowledge about CC to provide help. See local support companies. PTI in Israel, See support companies elsewhere, IRC channel and mailing list