Yolinux.com logo

YoLinux Editorial - Subversion vs Clearcase comparison:

This editorial discusses the comparison between using Subversion vs Clearcase for software change management.

Related YoLinux Tutorials:

°Subversion Commands

°Subversion and Trac server

°Subversion Repository Transfer

°Jenkins Build System (and Subversion)

°Cabie Build System (and Subversion)

°Clearcase Commands

°Clearcase Client

°Clearcase Server

°YoLinux Tutorials Index




Free Information Technology Magazines and Document Downloads
TradePub link image


Subversion vs Clearcase comparison:

  1. Clearcase operates in two modes (1) "Dynamic View" with a mounted "Multi-Versioned File System" (MVFS) which operates like a shared drive with a file system which supports change management or (2) "Snapshot View" which downloads the repository to the local filesystem in a similar fashion to Subversion. When using a "Dynamic View", Clearcase recommends that each user create and manage a new branch every time the developer wishes to work on code. This requires writing a new Clearcase "Configuration Specification" (config-spec) to use the branch. Although scripts are available to simplify the task, Clearcase is still a complex system requiring constant expert support. If the developer is working on two tasks, he will be switching config-specs when switching tasks. Subversion does not require this as the developer is always working with a local copy which can not be disturbed by the check-in of another developer. Both systems might require a merge if another developer has altered the same code. Thus for small projects without expert dedicated Clearcase support, Subversion is the clear winner. It is the Clearcase config-spec rules definition and generation required to view the CM repository which many find burdensome. Subversion is simple to administer and simple to use.

  2. Rapid development may lead to developers checking in code which breaks the build. Subversion always assigns a new version number to each check-in. Thus previous states can be recreated, checked out or viewed. Clearcase requires a "Clearcase Label" to be manually created to identify the current state. Any previous state of the code is lost completely in Clearcase as the system does not identify which versions of each file go together to define a build at any point in time, unless a "Clearcase Label" is applied. Use of Clearcase UCM will track code changes for a task.

  3. Cost. Subversion is free vs Clearcase license fees. It also seems to take a larger staff and more expertise to run a Clearcase installation.

  4. Subversion is easy to use in an Enterprise (nation wide or global) environment as it uses HTTP based web technologies. Clearcase "Dynamic Views" with MVFS uses a feature called "Multi-site" for this purpose. Since Clearcase dynamic views are a local mounted file system (MVFS) mirroring a shared Clearcase server file system, it does not lend itself to networks which can have unexpected latencies and momentary delays such as the internet. Clearcase multi-site overcomes this and is used to tie together remote locations. This requires a highly skilled Clearcase administrator. One could use Clearcase "Snapshot Views" to overcome this complexity. A recent Clearcase addition is the Remote Client. This is an Eclipse based client to interface with the Clearcase repository and said to simplify the user experience. No special considerations are necessary for Subversion in this environment.

  5. Both Subversion and Clearcase have a web interface for viewing the source code on the server. Subversion's is native as part of the installation with Apache. It is greatly improved when used with Insurrection or ViewVC. Clearcase on the other hand requires each developer to generate a static view on the Clearcase web server from which one can view the code via the web. The Clearcase web interface is poor (in 2006) and I can not recommend its use.

  6. Integration with task / bug tracking: Subversion integrates with Trac and other task/bug management tools. Trac and Subversion support two way tracking so that Subversion check-ins can reference a Trac ticket (specify track ticket eg. #165 in the Subversion comment) and Trac tickets can reference the Subversion check-ins (specify the Subversion check-in eg r879) supporting the Trac ticket. Hyperlinks to each other are automatically generated.
    Clearcase typically integrates with Rational Clearquest and now has a layer known as UCM to support the reference to all changes made in support of the "activity". UCM claims to remove the requirement that users manage the config-spec for the CM repository view. I have not used UCM but if true it would greatly improve the developer's experience with Clearcase.
    Here I find Subversion/Trac to be much simpler while Clearcase/Clearquest can support a much more complex environment with lots of customization possibilities. The level of sophistication can be regarded as too complex and too much of a burden but that will depend on the level of process complexity you are looking to support.

  7. Integration with regression testing: Subversion integrates with Jenkins, a multi-platform automated build and test tool. Jenkins is definitely a time saver as it compiles and tests the build on all platforms. It is perfect for rapid development as it tests the build upon each check-in. A plus for rapid development. There are interfaces available which allow Jenkins to interface with Clearcase. Clearcase typically integrates with Rational Buildforge.
Note that IBM has a new suite of integrated Application Lifecycle Management (ALM) tools based on their JAZZ framework known as Rational Team Concert.

Conclusion: It is the opinion of this author that complexity comes at a cost. Clearcase (and Clearquest/Buildforge) supports many ways of approaching CM with many levels of customization which may be required at some corporations but at the cost of difficulty to administer and use. I find that the open source quartet of Subversion (and ViewVC/Trac/Jenkins) perform at a reasonable level of sophistication without the burden of over complexity on either the programmer or the administrator.

   

    Bookmark and Share


Advertisements




Copyright © 2007-2011 YoLinux.com