This documentation relates to an earlier version of FishEye.
View

Unknown macro: {spacejump}

or visit the current documentation home.

End of Support for ClearCase

On April 4th 2012, we are ending FishEye support for IBM ClearCase. For more information, see End of Support Announcement for IBM ClearCase.

This page contains instructions for how to set up a ClearCase repository in FishEye, a configuration reference and a list of known issues.

(info) If you also have Crucible, you will also be able to run Crucible reviews on code from your ClearCase repository, once configured.

On this page:

Requirements

The instructions on this page require the following:

Applications:

  • IBM ClearCase 2003.06.10 or later
  • The cleartool command must be installed on the same server as FishEye and must be available in the PATH of the user that is running FishEye.

Permissions:

  • The FishEye process must be run as a user that is part of the required groups with access to the ClearCase VOBs. This is because FishEye uses the Cleartool client to access VOBs, and ClearCase uses the user and group information from the operating system to grant or limit access to VOB content.

Setting up a ClearCase Repository

To add a ClearCase repository,

  1. Open the 'New Repository' dialogue by following the instructions on Adding an External Repository.
  2. Set your ClearCase repository details, as described below. Also see the screenshots below.

1. Enter the Basic Repository Details

Field

Description

Allowed values

Repository Type

Select 'ClearCase'.

ClearCase

Name

Enter a display name. This name will be displayed in the list of FishEye repositories.

Free text

Description

Optionally enter a description for this repository.

Free text

2. Enter the ClearCase Settings

Field

Description

Allowed values

View Location

If 'Auto Create View' is ticked, enter the location of a directory accessible to the FishEye instance where snapshot views can be created.
If 'Auto Create View' is not ticked, enter the location of an existing ClearCase view. This can be either a dynamic or a snapshot view. (Note, this is not the view storage location typically .vws directory).

A system path

Auto Create View

Tick the checkbox, if you want FishEye to create views for each VOB or UCM Project being indexed.
Do not tick the checkbox, if you want FishEye to use an existing view (specified in the 'View Location' field below).

Yes/No

UCM

Choose whether the underlying ClearCase repository uses UCM or Base ClearCase.
The rest of the fields on this screen will change depending on which option you choose (see screenshots below)

Yes / No

If you have selected 'UCM' to be 'No' (i.e. you are configuring a Base ClearCase repository) complete the following fields:

Field

Description

Allowed values

Main Branches Only

Tick this checkbox, if you only want changes made on the main branch or delivered to the main branch to be indexed. Do not tick this checkbox, if you want all changes to be indexed.

Yes / No

Index Start Date

Enter an index start date, if you only want changes that were made after this date to be indexed. Note, files that have not changed since the index start date will not be displayed at all.

Date (YYYY-MM-DD)

Block Size

Enter the block size, i.e. how many change sets FishEye and Crucible will process in one batch.
(This setting only displays if you tick the 'Show advanced settings' checkbox at the bottom of the dialogue.)

Number

Command Timeout

Enter how long you want FishEye and Crucible to wait for ClearTool commands to complete, e.g. "100000". If not set, this will default to "3600000".
(This setting only displays if you tick the 'Show advanced settings' checkbox at the bottom of the dialogue.)

Number (in milliseconds)

VOB to Include

If you only need FishEye to index a single VOB, select the VOB to index. The dropdown list will contain all non-UCM VOBs found in the ClearCase installation.

Auto-populated

Include Pattern

If you need FishEye to index multiple VOBs, use a pattern to specify which VOBs to include. Multiple inclusion patterns can be separated with a comma.
See the Inclusion/Exclusion Settings section for examples of inclusion patterns.

Free text

Exclude Pattern

If you need FishEye to index multiple VOBs, use a pattern to specify which VOBs to exclude. Multiple exclusion patterns can be separated with a comma.
See the Inclusion/Exclusion Settings section for examples of exclusion patterns.

Free text

Branches to Include

Enter the list of the branches to include in indexing. An empty list will cause all branches to be indexed.

Table

Branches to Exclude

Enter the list of the branches to exclude from indexing.

Free text

If you have selected 'UCM' to be 'Yes' (i.e. you are configuring a UCM ClearCase repository) complete the following fields:

Field

Description

Allowed values

Integration Streams Only

Choose whether FishEye and Crucible should index changes made on development and integration streams or only integration streams. We recommend that users choose 'Yes' for this option.

Yes / No

Include Integration Activities

Choose whether to include integration activities, i.e. when enabled, rebase and deliver activities will also be indexed.

Yes / No

Index Start Date

Enter an index start date, if you only want changes that were made after this date to be indexed. Note, files that have not changed since the index start date will not be displayed at all.

Date (YYYY-MM-DD)

Block Size

Enter the block size, i.e. how many change sets FishEye and Crucible will process in one batch.
(This setting only displays if you tick the 'Show advanced settings' checkbox at the bottom of the dialogue.)

Number

Command Timeout

Enter how long you want FishEye and Crucible to wait for ClearTool commands to complete, e.g. "100000". If not set, this will default to "3600000".
(This setting only displays if you tick the 'Show advanced settings' checkbox at the bottom of the dialogue.)

Number (in milliseconds)

Project To Include

A drop down list displaying all the UCM Projects found in the ClearCase installation. If users only require that FishEye index a single UCM Project, they should select the Project to index from this drop down list. If 'Auto Create View' is set to 'False' (i.e. using an existing view), you must select a single project not 'All', as a view can only be used for a single UCM project.

Auto populated

Project Include Pattern

If you need FishEye to index multiple UCM Projects, use a pattern to specify which UCM Projects to include. Multiple inclusion patterns can be separated with a comma. See the Inclusion/Exclusion Settings section for examples of inclusion patterns.

Free text

Project Exclude Pattern

If you need FishEye to index multiple UCM Projects, use a pattern to specify which UCM Projects to exclude. Multiple exclusion patterns can be separated with a comma. See the Inclusion/Exclusion Settings section for examples of exclusion patterns.

Free text

Streams to Include

Enter the list of the UCM streams to include in indexing. An empty list will cause all streams to be indexed.

Free text

Streams to Exclude

Enter the list of the UCM streams to exclude from indexing.

Free text

3. Enter the Final Settings

Field

Description

Allowed values

Store Diff Info

Choose whether to enable the Store Diff Info setting. See Store Diff Info for more information on this setting.

Yes / No

Enable Repository After Adding

Choose whether the repository will be accessible in FishEye immediately.

Yes / No


Screenshots: Adding a ClearCase Repository (click to view gallery)

Notes

Inclusion/Exclusion Settings

The following points provide guidelines for the settings which may need to be applied in order to restrict the number of ClearCase Projects/VOBs indexed by FishEye:

  • If you want all the VOBs/UCM Projects within your environment to be indexed, then you don't need to add any additional information on the Edit Repository screen. This is the default behaviour.
  • If you want several VOBs/UCM Projects to be included (but not all), then you should include appropriate details in the VOB Includes/Excludes fields
  • If you only wish for a single VOB/UCM Project to be indexed, then you should select the specific VOB/UCM Project from the 'VOB to Include' or 'UCM Project to Include' drop down list. This will force FishEye to only index the selected VOB/UCM Project.

When using the Includes/Excludes fields, you can enter one or more patterns, separated by a comma (note, you cannot use spaces). A pattern can be either a regular expression or a plain string. Matching is done as follows:

  • A plain string pattern is considered to match a VOB or UCM Project if the string is part of the VOB/UCM Project (e.g. myvob matches vob:/vobs/myvob and vob:/vobs/myvob2)
  • A regular expression is considered to match a VOB or UCM Project if it is the regular expression matches the VOB/UCM Project string (e.g.  project:.*_Release.* matches project:Product1_Release2.1@/my_pvob)

For Base ClearCase configurations, the patterns are matched against the VOB name as listed in the select box (e.g. vob:/vobs/yourvob):

VOB Include/Exclude Pattern

Description

/vobs/myvob1,/vobs/myvob2

matches /vobs/myvob1 and /vobs/myvob2, but also /vobs/myvob12

vob:/vobs/.*vob

regexp pattern that matches /vobs/myvob, /vobs/yourvob, but not /vobs/myvob2

vob:/vobs/.*vob,/vobs/myvob1

combination of a regexp pattern and a simple VOB name.

For UCM ClearCase configurations, the patterns are matched against the full UCM Project as listed in the select box (e.g. project:MyUCMProject@/my_pvob):

UCM Project Include/Exclude Pattern

Description

MyProduct1,MyProduct2

matches all UCM projects whose name contains MyProduct1 or MyProduct2 (e.g. MyProduct12_Rel3.1)

project:MyProduct_Rel\d+.*

regexp pattern that matches MyProduct_Rel1, MyProduct_Rel2, but not MyProduct_CoolNewFeature

.@/my_pvob,.@/my_otherpvob

regexp patterns that match all UCM projects in the /my_pvob and /my_otherpvob PVOBs.

View Creation

As part of the repository scanning logic, FishEye will create a view for each Project (for ClearCase UCM environments) or VOB (for Base ClearCase) using the locations defined in the 'View Location' and 'View Storage Location' fields. This is required in order for the underlying 'cleartool' commands to be executed in the correct context. Please note that FishEye will not perform updates on these views - it is intended that these views will remain unpopulated.

Indexing Logic

It may be helpful to understand how FishEye's ClearCase support carries out indexing. Please see the following sections:

UCM ClearCase Indexing:
The ClearCase support will attempt to index all the available content within a ClearCase environment. The logic works as follows (ClearCase specific terms are underlined see definitions):

  • All PVOBs that are available are identified.
  • For each PVOB, find all the Projects contained within the PVOB.
  • For each Project, find all the Streams associated with the Project.
  • For each Stream, find all the Activities that have been delivered to the project.
  • Find the Versions that were included in each Activity and index the Version information.
  • Any Labels attached to Versions are also indexed.

(info) PVOB stands for Project Versioned Object Base.

Base ClearCase Indexing:

The logic for the Base ClearCase support is,

All non-UCM VOBs that are available are identified.

  • For each VOB, find all the Branches that contain versions.
  • For each Branch, find the check-ins and index the version information.
  • Any Labels attached to Versions are also indexed.

Allocating Time for Repository Scanning

The initial scan of a repository is a time and resource intensive operation, more so if the ClearCase repository being indexed is large (both in terms of the number of ClearCase projects and the number of change sets included in each project). In the Atlassian test environment (running in a virtual machine), each commit included in a change set would take approximately one second to complete (the time taken in a non-VM environment seems to be slightly faster at approx 700ms). You can use these numbers to estimate the time it will take to scan your repository; it could take many hours or possible days to complete.

Changelog

Changes included in 2.1.3

Config.xml schema changes:
The structure of the underlying schema for the ClearCase configuration config.xml file has changed. The effect of this is that for repositories created prior to version 2.1.3, the VOB/UCM Project Inclusion rules won't appear in the Administration UI. However, the previously entered values for these fields will still be used as part of the repository scanning logic.

In order for these fields to be displayed in the Administration UI, the values for these fields should be re-entered.

Interactive invocation of cleartool commands:
As a performance improvement measure, a number of the cleartool commands executed by FishEye as part of the repository scanning logic are now executed in 'interactive' mode. That is, a cleartool process (one per repository) is kept open for the duration of the indexing process.

The execution of commands in interactive mode can be disabled by adding a 'disableInteractiveProcess' attribute to the specific ClearCase repository defined in the config.xml file.

Performance Improvements:
Subsequent indexing operations for Base ClearCase repositories will take the last indexed date into account, so the 'cleartool lshistory' output will only include those changes that have not already been indexed.

Changes included in 2.1.2

In the first release, the include/exclude rules for VOBs and Projects were handled by the 'Include/Exclude' rules item on the administration page. Based on feedback received during initial version testing, this has been updated to provide additional flexibility:

  • The VOBs which are indexed can be controlled via the 'VOB to Include' and 'VOB Include/Exclude Patterns' fields.
  • Similarly, the UCM Projects which are indexed can be controlled via the 'UCM Project to Include' and 'UCM Project Include/Exclude Patterns' fields.
  • The Include/Exclude rules on the Administration page now apply to files/directories that are indexed within a ClearCase VOB/Project. The values entered into these fields perform the matching logic as defined on the Allow (Process) page

Text Types

From version 2.5.6 FishEye allows you to specify a file which lists the types which are to be considered as text types. If a file 'types.txt' is found in the FISHEYE_INST root directory, FishEye will load this file. Each line in this file is considered to be the name of a Clearcase type which is to be considered a text type. When FishEye detects a file of a type which matches a line in this file, it will remap the type to 'text_file' internally. FishEye will not treat such files as binary.

There is only a single file for all Clearcase repositories in a FishEye instance and all Clearcase repositories will use this file. To pick up changes in this file, a repository must be restarted. The mapping must be in place before FishEye indexes a revision with that type otherwise FishEye will indicate the file is binary. Addition of a type to the list in 'types.txt' after FishEye has indexed revisions of that type will require the repository to be reindexed to pick up that change.

Known Issues

There are a number of known issues with ClearCase support in FishEye. These are listed below.

XML files cannot be viewed as 'Annotated' source

Currently XML files cannot be viewed as 'Annotated' source. By default, ClearCase using a specific type manager to store XML files. This type manager does not support the 'cleartool annotate' command, which is used by the logic in FishEye that displays the Annotated source.

Further to this, by default ClearCase treats any files not defined in the 'default.magic' file as 'compressed' (for instance, property files are not included in the default.magic file). Only text-based type managers can be annotated (and hence, can be displayed via the 'Annotated Source' link). The type manager can be updated by performing the following steps:

  1. Update the default.magic file to include appropriate rules that specify the type manager to use for files of a given naming convention (this will take effect for newly created elements)
  2. Modify the type manager for existing elements through the 'cleartool chtype' command.

Further information on the ClearCase type manager is available on the following pages:

Cleartool output limited to 64K of data

There is a known bug with earlier versions of ClearCase that limit the Cleartool output to 64K of data. This may affect projects that contain a large amount of changes included in a changeset. This bug can be fixed by upgrading ClearCase — see this page for more information.

Feedback and Support

Please raise a support ticket to seek assistance with FishEye ClearCase support.

  • No labels

22 Comments

  1. Anonymous

    Where do we configure the username and password? 

    1. Ross Rowe [Atlassian]

      Hi, the ClearCase support uses the logged on users credentials when running the cleartool commands.

      Cheers,

      Ross

  2. Anonymous

    Another bug I noticed is that on the Edit Repo screen, the UCM label appears twice.

    1. Ross Rowe [Atlassian]

      Hi, thanks for pointing that out, I've raised FE-2177 for the bug.

      Cheers,

      Ross

  3. Anonymous

    In our environment we have several pvobs, vobs, and ucm projects.  We would like to set fisheye to view one particular project.  How best to configure for one specific Ucm project and would would the format look like?  Is there an example of how the format the includes/excludes for fisheye?

    1. Ross Rowe [Atlassian]

      Hi, if you only wish FishEye to index a single UCM project, then I would suggest including an 'Include' rule which is set to the UCM Project's name. This should ensure that only that project is indexed. The include rule matching logic will check to see if the name of the Project is either equal to, contains or matches (ie. regular expression) the value entered into the 'includes' field.

      There is an open issue that relates to allowing more flexibility in the include rules (FE-2176). A fix for this issue will be released in the next alpha release.

      Cheers,

      Ross

  4. Anonymous

    You warn against using this in production, but there doesn't seem to be any intuitive way to specify a single test VOB for import/scanning. Is there a way to set up a single repository? The notion of a "repository" as its defined in the interface doesn't map one for one to a VOB - you've got us defining a repository at a high level, but then it just goes off and tries to import every VOB - doesn't seem all that intuitive.

    If there's a way to just grab a single VOB per repository definition, that would be a big help for evaluation purposes. Some of our VOBs are massive. I'd like to just pull in a single VOB for eval purposes.

    Thanks,

    Tom Bennett

    bennett_tom@emc.com

    1. Ross Rowe [Atlassian]

      Hi Tom, thanks for your feedback.  I'd recommend that you try to specify an 'Includes' rule that only matches a single VOB - if an Includes rule is specified, then only VOBs/UCM Projects which match that rule will get processed.  We are making some improvements to the repository administration screen in the next Alpha version which should provide a bit more flexibility in specifying the VOB, Projects and Paths to index.

      Thanks,

      Ross

      1. Anonymous

        Hi Ross,

        Found that feature, but it didn't appear to be working.

        VOB name was /vobs/ms-test so I added that to the include list, but when I checked the load, it appeared to be loading everything again. What works in this field? Regex? It wasn't clear.

        Thanks!
        Tom

        1. Ross Rowe [Atlassian]

          Hi Tom, would you be able to try entering 'ms-test' as the include rule (without the quotes)? The include rule matching logic will check to see if the name of the Project is either equal to, contains or matches (ie. regular expression) the value entered into the 'includes' field.

          Please feel free to email me if you have any further problems.

          Thanks,

          Ross

          1. Anonymous

            Hi Ross,

            Thanks much for the response.

            Doesn't matter all that much how I specify it, regardless of what I do, I get a raft of views, one for each of my VOBs getting created in the view location that I specify. 

            I just want one project, consisting of a single, small repository for testing/eval.

            Thanks!

            -tom

            1. Ross Rowe [Atlassian]

              Hi Tom, we've been working on a solution to your issues for inclusion in the next Alpha release, I've included some details on how we're going about addressing on our forums at http://forums.atlassian.com/thread.jspa?messageID=257322634&#257322634

              Cheers,

              Ross

  5. Anonymous

    I'm using 2.2, but there's no explanation in this documentation on what the Autocreate View option does. 

    1. Ross Rowe [Atlassian]

      Hi, sorry about that, I've now included a description of the Autocreate View option.

  6. Igor Kozhukhov(gmail)

    Hello All,

    Could you please reply who may know about configuration this tool with ClearCase dynamic views ?

    At this moment I have tested only with ClearCase snapshot.

    I'm interested about dynamic views and dynamically update CS for findings new files.

    Best regards,

    Igor Kozhukhov

    1. Ross Rowe [Atlassian]

      Hi Igor, our initial testing indicates that configuring FishEye to use an existing dynamic view seems to work okay.  You shouldn't need to do anything special in order to use a dynamic view instead of a snapshot view, you just need to enter the path to the dynamic view in the 'View Location' field.

      Please let us know if you encounter any problems via our support pages.

      Thanks,

      Ross

  7. Anonymous

    In he above page

    • For each Project, find all the Activities that have been delivered to the project.

    We would like to code inspect CHECKED-IN code in activities before them being
    delivered to the integration stream. If this is the case, we won't be able to include
    changesets of undelivered activities to a crucible review?

    Caner Arda

    1. Ross Rowe [Atlassian]

      Hi Caner, I've raised http://jira.atlassian.com/browse/FE-2574 for this functionality.  The Pre-Commit functionality available within the Atlassian IDE Connector could possibly help, but I don't think that the IDE Connector has been updated to work with the ClearCase support in Crucible/FishEye.

      Thanks,

      Ross

  8. Anonymous

    Hello,

    I'm evaluating FishEye for my project now, and I cannot get my CC project being indexed all right. I enabled the DEBUG logging and I can tell now that FishEye executes cleartool lshistory commands, but then it prints out the following message:

    ClearCaseUCMContext-getChangeSets - No activities were defined for stream: stream:MP_Integration@\UCM

    When I execute the same cleartool command with same parameters as FishEye logs - it generates a list of CC activities all right. So it seems like FishEye gets the output but cannot see any activities in it :(

    Then, the strange thing is: when I select another one project - it works all right! In fact, it works all right with all of my projects, except this one, which, ironically, I need most of all. I understand it might be that this project is configured in CC differently, but I don't know what exactly causes this issue.

    I'm using UCM repository, and I select one project only. I tried using existing views, and auto-generated views; I tried checking the "Integration Streams Only"; I tried including one stream only (integration), or including all streams - all with no effect.

    Does anyone have an idea why this happens? Why would FishEye say there is "No activities were defined for stream"? Thank you much for any hint!

    Thank you!, Timur Rubeko

    1. Conor

      Timur,

      I suggest you either raise a support request at http://support.atlassian.com/ or ask a question at https://answers.atlassian.com/

      Please also note the warning at the top of this page: Clearcase support in FishEye will be removed after April 4th, 2012.

      1. Anonymous

        Thanks! Did that (raised the support request). 

        Yes, thank you, I know about end of support for CC, and I plan to migrate to Git, but this takes some time...

        Thank you,

        Timur.

  9. Jean-Charles Crépeau

    Dear Atlassian users,

    I wanted to know a bit more about setuping to use Crucible with ClearCase. We are preparing to migrate our ClearCase repositories to Git, which will probably take a few months, and would

    like to be able to use Crucible with ClearCase for the remaining months. We bought a license for Crucible v2.7.11 and are using ClearCase 7.0.1.5

    Actually our FishEye/Crucible server is on RedHat 4.0 and ClearCase is not installed on it, I hoped it was possible to configure Crucible (or the ClearCase plugin) to communicate with an external ClearCase server to connect to remote repositories. I thought about creating a mount point mapping the main view/stream path onto the ClearCase server, but don't think it's a good idea or if it's even feasible.

    The documentation says that the cleartool command must be installed on the server where Crucible/FishEye is installed, but what about ClearCase itself ? What ClearCase components, packages, patches must be installed on the Crucible/FishEye server to allow working with ClearCase? Maybe this documentation exists and is detailed in a page I have not found yet ?

    Thank you very much for helping me out!

    J-C