Administering the Workspace

10

Moving an Existing Project

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

• Be sure that your project directory structure is current and organized.

• Execute the Create Workspace command item in the File menu, specifying the top-level directory as your workspace. The Create Workspace command creates the Codemgr_wsdata directory under the top-level directory.

• Begin using the Bringover Create transaction to form a workspace hierarchy. See "Structuring Your Workspace Hierarchy" on page 124 for guidelines regarding workspace hierarchies.

If your project requires files to be grouped for transfer operations in special ways, you have to write your own FLP(s).

Starting a New Project

• Use the Create Workspace command item in the File menu to create your project's top-level directory (with its Codemgr_wsdata directory)

• Proceed as you normally 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.

• Begin using the Bringover Create transaction to form a workspace hierarchy. See "Structuring Your Workspace Hierarchy" on page 124", for guidelines regarding workspace hierarchies.

• 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.

---

Note - Whatever initial decisions you make regarding workspace hierarchies can later be changed by using Configuring's workspace reparenting feature. See "Reparenting a Workspace" on page 66 for details.

---

File System Accessibility

Flat Hierarchy vs. Multitiered Hierarchy

Disadvantages of a Flat Hierarchy

Advantages of a Multitiered Hierarchy

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

• Each new workspace consumes disk space.

• Developers who ought regularly to be looking at one another's work may find it harder to do so because they do not put back to the same integration workspace

• Integration of the subintegration workspaces to the higher integration workspace can become more complicated than more frequent, smaller integrations.

It's best to dedicate a workspace as a product release staging area for each release. It's also a good idea to "hang" the release workspace off of a top level "product" workspace. The product workspace should be located hierarchically above the workspaces in which normal development integration is done. Locating the product workspace this way permits you to begin development of your next release without corrupting the current release.

After the files are transferred to the product workspace, use the Bringover transaction to transfer the files down to the release workspace. The release workspace can be used to make masters and can serve as an area in which to save work for subsequent releases if necessary. Figure 10-3 shows a hierarchy that contains a product workspace and release workspaces for six different releases. You can use the reparenting feature to transfer data between release workspaces directly. See "A Reparenting Example" on page 68" for details.