test

Sun WorkShop TeamWare 2.1 User's Guide

Starting a New Software Development Project with Sun Workshop TeamWare

To start a new project with Sun Workshop TeamWare:

  1. Choose File > Create Workspace to create your project's top-level directory (with its Codemgr_wsdata directory)

  2. Proceed as you would to set up an SCCS-based development hierarchy.

    Ensure that all SCCS history files ("s-dot-file") are in directories named SCCS located directly beneath directories that contain source files.

  3. Use the Bringover Create transaction to form a workspace hierarchy (see "Creating a Workspace From an Existing Hierarchy of Files ").

    See "Configuring a Workspace Hierarchy", for guidelines regarding workspace hierarchies.

    Note -

    The default Configuring FLP groups files recursively by directory; if you intend to use that FLP, be sure to arrange files in compilation units accordingly. If your project requires that files be grouped differently during transfer, be sure to arrange your project hierarchy in such a way that it works well with the FLP(s) you will create.

Configuring a Workspace Hierarchy

How you configure a project workspace influences the interworkspace file-transfer process and the way you prepare product releases. This section will help you choose the workspace hierarchy best suited for your project. You can change any decisions you make now regarding workspace hierarchies by using the Configuring workspace reparenting feature. See "Reparenting a Workspace" for details.

A workspace hierarchy is a chain of parent and child workspaces that is two or more layers deep. The number of layers in a hierarchy bears no relation to the number of workspaces comprising it. A parent workspace and its child comprise two layers. A parent workspace and three children also comprise two layers. A parent workspace and its child and grandchild comprise three layers. Figure 5-1 depicts a "flat" (three-tiered) hierarchy, and Figure 5-2 shows a "multitiered" (four-tiered) hierarchy.

Figure 5-1 A "Flat" (Three-Tiered) Hierarchy

Graphic

Figure 5-2 A "Multitiered" (Four-Tiered) Hierarchy

Graphic

File Transfer Considerations

The way in which you set up your workspace hierarchy can have an impact on the transfer of files up and down the hierarchy.

File System Accessibility

In order to transfer (Bringover/Putback) files between workspaces, both the parent and the child must be mounted on the same file system. The automounter can be used to connect file systems.

Flat Hierarchy vs. Multitiered Hierarchy

To properly design your workspace, you need to be aware of the advantages and disadvantages of flat and multitiered hierarchies.

Advantages of a Flat Hierarchy

A flat workspace hierarchy is one in which many developers put back files to a single integration workspace. The advantage of a flat hierarchy is that all developers have immediate access to one another's work. The moment that Jack (a developer) puts back his work to the integration workspace, Jon (another developer) can use the Bringover Update transaction to have immediate access to the changes made by Jack.

Disadvantages of a Flat Hierarchy

The disadvantage of a flat hierarchy is that time is often wasted because the integration workspace changes frequently, requiring developers to do frequent Bringover transactions, builds, and tests in order to keep their source base up-to-date. There is a cumulative effect of doing Putback transactions; the first developer to do a Putback resolves only one set of changes, the next developer resolves two, and so on till the last developer, who must resolve all of the changes that have been made within her development group.

Advantages of a Multitiered Hierarchy

The amount of time required for a developer to put her work back to the integration workspace can be sharply reduced by interposing a tier of subintegration workspaces between the integration and development level workspaces.

Whenever a developer puts back work to an integration workspace, there is some chance that the next developer to do a Putback transaction will not be able to put back their changes until they bring over the earlier changes, rebuild the modules, and test the new changes with their own--the more Putbacks that occur the higher the potential for conflict.

When many developers work on a project, the Bringover, rebuild, test cycle can become onerous and time consuming. If smaller groups of developers working on related portions of code integrate into a subintegration workspace, that workspace will be more stable and require fewer builds and less testing. Of course when the subintegration workspaces are themselves put back to their common integration area, changes made in the other development workspaces will have to be integrated. Experience has shown, however, that doing larger integrations, less frequently, is more efficient.

Disadvantages of a Multitiered Hierarchy

The disadvantages of multiplying subintegration workspaces are as follows: