Constraints of a multi-user environment – PB Docs 125

Best practices

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

Project manager’s tasks

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:

• Distributing any target (PBT) files and PBLs that are added to the workspace
  during the course of development, or maintaining them on a network
  directory in an appropriate hierarchical file structure

• Making sure the PBL mapping
  files (PBGs) do not get out of sync

  For information about the PBG files, see “Editing the PBG file for
  a source-controlled target”.

Connections from each development computer to the source control
project can be defined on the workspace after the initial setup
tasks are performed.

Developers’ tasks

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

For more information about getting the latest version of objects
in source control, see “Synchronizing objects with
the source control server”.