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.
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 targetsThis 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
projectIdeally, 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
syncFor 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.