User development environments are customizable, yet some standards and best practices help ensure smooth tool usage:
- Use Team Project Set to group the related projects
- Establish common preferences settings in your organization
- Search for checkout elements at the project level
- Avoid duplicate storage of components and elements
- Avoid sending huge files over the network
- Perform the administrative task of determining the optimum physical location for your servers. The physical location of the servers in a ClearCase environment is very important.
- Allow users flexibility, yet make the risks of deviating from standard practices known.
- Access the numerous configurations available via Preferences
- See Window > Preferences
- You can set "Ignored resources"
The most important items in this list are explained in the following sections.
Team Project Set becomes important when your teams are doing parallel development in a producer-consumer environment, especially when an application needs multiple projects to function correctly. That forces everyone who wants to use this application to download all of the related projects to be successful. If there are fewer projects, making this mistake is less likely. But if an application includes dozens of projects, chances are good that someone on the team will forget to download some projects.
One way to ensure that all projects are handled as a single unit is to use Team Project Set. Using Team Project Set maintains an index file of the name and the physical location of the projects. When you import the index file, which is generally called a Team Project Set file, it imports all related projects into your workspace.
Many CCRC preferences can influence the control behavior and appearance of the ClearCase operations. Each of them can be customized to meet business needs. Some preference settings, with the related available options, are shown below. To see all preference settings, click Window > Preferences
- After new resources are added to source control:
- To have the ClearCase Remote Client add the resources to source control and then check them out, select Automatically checkout.
- To keep the newly added resources checked in, select Do nothing.
- When checked-in files are edited or saved by an Eclipse editor, you can either:
- Automatically checkout.
- Prompt to checkout
- Hijack Options for Checkout:
- To prevent the ClearCase Remote Client from hijacking the file when a checkout is not possible, select Do not hijack.
- To allow hijacking only when you are disconnected from the ClearCase Web server, select Hijack only if disconnected.
- To force a hijack even when a checkout is possible, select Always Hijack.
These preferences can be stored in a file (typically with the file extension .epf) inside the ClearCase repository for the team to share and reuse. Using common preferences helps you establish common ClearCase usage patterns, which can avoid unnecessary debates and discussions during collaborative development.
Search for Checked out elements
When you work in a J2EE project, many files are updated without your knowledge (as a developer), because the IDE follows the J2EE specification. Unfortunately, you cannot and will not know all of the files and directories that are affected when you create even a small Enterprise Java™Bean (EJB) component.
If your preference setting is Do Auto Check out, most of the J2EE metafiles are checked out without the knowledge of the developer. It will be a tough task for that developer to find all of the items for checkin. For example, a file like .../.settings/org.eclipse.wst.common.project.facet.core.xml must be checked in if there is an update to it. How do you know which elements you have checked out? In order to avoid potential pain and mistakes, be sure to run the ClearCase operation Search for all the Checked out elements at the Project level.
No comments:
Post a Comment