Constraints of a multi-user environment

Any object added or checked into source control should be usable by all developers who have access permissions to that object in source control. This requires that the local paths for objects on different computers be the same in relation to the local root directory where the PowerBuilder workspace resides.

The source control administrator should decide on a directory hierarchy before creating a source-controlled workspace. The following practices are highly recommended for each target under source control:

• Create a top-level root directory for the local project path on each developer workstation.

  This directory becomes the project path in the SCC repository. The local workspace object (PBW), the offline status cache file (PBC), the source control log file, and any Orcascript files used to rebuild and refresh the source-controlled targets should be saved to this top-level directory on local workstations

• Create a unique subdirectory under the project path for each PBL in the source-controlled targets

  This practice avoids issues that can arise if you copy or move objects from one PBL to another in the same target.

• Instruct each developer on the team to create a workspace object in the top-level directory and, on the Source Control tab of the Properties of Workspace dialog box, assign this directory as the "Local Project Path". Each developer must also assign the corresponding top-level directory in the SCC repository in the "Project" text box of the Source Control tab for the workspace

• Add target files (PBT) to the project path directory or create unique subdirectories under the project path for each target file

Before developers can start work on PowerBuilder objects in a workspace under source control, a project manager usually performs the following tasks:

• Sets up source control projects (and archive databases)

• Assigns each developer permission to access the new project

• Sets up the directory structure for all targets in a project

  Ideally, the project manager should create a subdirectory for each target. Whatever directory structure is used, it should be copied to all computers used to check out source-controlled objects.

• Distributes the initial set of PBLs and target (PBT) files to all developers working on the project or provides a network location from which these files and their directory structure can be copied.

PowerScript and .NET targets require that all PBLs listed in a target library list be present on the local computer. For source control purposes, all PBLs in a target should be in the same local root path, although they could be saved in separate subdirectories. PBWs and PBLs are not stored in source control unless they are added from outside the PowerBuilder SCC API. They cannot be checked into or out of source control using the PowerBuilder SCC API.

If you are sharing PBLs in multiple targets, you can include the shared PBLs in a workspace and in targets of their own, and create a separate source control project for the shared objects. After adding (registering) the shared PBL objects to this project, you can copy the shared targets to other workspaces, but the shared targets should not be registered with the corresponding projects for these other workspaces. In this case, the icons indicating source control status for the shared objects should be different depending on which workspace is the current workspace.

For small projects, instead of requiring the project manager to distribute PBLs and target files, developers can create targets in their local workspaces having the same name as targets under source control. After creating a source control connection profile for the workspace, a developer can get the latest version of all objects in the workspace targets from the associated project on the source control server, overwriting any target and object files in the local root path. (Unfortunately, this does not work well for large PowerScript or .NET projects with multiple PBLs and complicated inheritance schemes.)

Ongoing maintenance tasks of a project manager typically include:

Each user can define a local root directory in a workspace connection profile. Although the local root directory can be anywhere on a local computer, the directory structure below the root directory must be the same on all computers that are used to connect to the source control repository. Only relative path names are used to describe the location of objects in the workspace below the root directory level.

After copying the directory structure for source-controlled PowerScript or .NET targets to the local root path, developers can add these targets to their local workspaces. The target objects can be synchronized in PowerBuilder, although for certain complex targets, it might be better to do the initial synchronization through the source control client tool or on a nightly build computer before adding the targets to PowerBuilder. (Otherwise, the target PBLs may need to be manually rebuilt and regenerated.)