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.
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)
Step 1
Step 2a (Base)
Step 2b (UCM)
Step 3
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 underlinedsee 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.
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:
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)
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:
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.
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?
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.
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.
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.
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.
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.
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.
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.
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?
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.
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!
21 Comments
Hide/Show CommentsOct 08, 2009
Anonymous
Where do we configure the username and password?
Oct 08, 2009
Ross Rowe [Atlassian]
Hi, the ClearCase support uses the logged on users credentials when running the cleartool commands.
Cheers,
Ross
Oct 08, 2009
Anonymous
Another bug I noticed is that on the Edit Repo screen, the UCM label appears twice.
Oct 08, 2009
Ross Rowe [Atlassian]
Hi, thanks for pointing that out, I've raised FE-2177 for the bug.
Cheers,
Ross
Oct 12, 2009
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?
Oct 13, 2009
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
Oct 29, 2009
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
Oct 29, 2009
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
Oct 30, 2009
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
Oct 30, 2009
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
Nov 02, 2009
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
Nov 02, 2009
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�
Cheers,
Ross
Feb 23, 2010
Anonymous
I'm using 2.2, but there's no explanation in this documentation on what the Autocreate View option does.
Feb 24, 2010
Ross Rowe [Atlassian]
Hi, sorry about that, I've now included a description of the Autocreate View option.
Mar 10, 2010
Igor Kozhukhov
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
Mar 10, 2010
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
Apr 19, 2010
Anonymous
In he above page
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
Apr 26, 2010
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
Aug 11, 2011
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
Aug 11, 2011
Conor MacNeill
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.
Aug 12, 2011
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.
Add Comment