Tips for Successful Sessions

This topic presents some tips for successful View Compare/Merge sessions.

In this topic:

Prepare Data

StarTeam allows you to do almost anything you want to your data. However, this can result in conditions which a View Compare/Merge session cannot make decisions without your input. It is best to get your data into the best possible shape and keep it there.

• When a branching item (folder, file, or change request) is the root branch, or is the first share of a new branch, (1.x), its behavior should be disabled, and its configuration should be floating. Pinning its configuration makes it read-only.
• When not the first share of its branch, branching items (folders, files, and change requests) should be set to branch on change (behavior), and have a pinned configuration.

Some customers make exceptions for this. For example, they might want all change requests visible from all views, regardless of where they were created. So, they share the same change request folder into each child view, but they set the folder and the change requests to not branch on change and to be floating. This is not a best practice, but can be used, carefully. Because the change request never branches, when they use a change request from any view as a process item, they are essentially using an out-of-view process item from the main view. That means that they should be using enhanced process links (like all users who use out-of-view process items).

Other customers put all change requests in the main view and always select them as out-of-view process items. They usually make a copy of each change request for each maintenance or release view in which the change request needs to be fixed. This allows each change request for a given problem to take separate workflow steps, or, the same steps but at different times. The copies are also in the main view.

Back to top

Follow Best Practices

If you follow best practices, the only time you will run into problems is when you share items into a new location. This gives the following results:

• The shared items have the behavior determined by the view property Set items shared into view to branch on change check box, which we recommend to be checked. This property is ignored for items that cannot branch.
• When dealing with an item that cannot branch (a task, requirement, or topic), pinning its configuration makes it read-only, so you want to use it in only one view at a time. For example, for a task that is created in an activity view, it often makes sense to promote the task along with the changed files. Once the task is promoted, it becomes read-only in the activity view, and you will use it in the parent. This continues up the view hierarchy until the task and its associated changes have been promoted to the root.
• The shared items will be floating. You will need to set their behaviors to branch on change.

Back to top