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 Case | UCM | Subversion |
|---|
| 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 |
