About this chapter
PowerBuilder provides native interfaces to Subversion (SVN) and Git source control systems, and a direct connection to the PowerBuilder native (PBNative) check in/check out utility and external SCC-compliant source control systems. This chapter describes how to work with source control.
This section provides an overview of source control systems and describes how PowerBuilder integrates with these systems' interfaces.
What source control systems do
Source control systems (version control systems) track and store the evolutionary history of software components. They are particularly useful if you are working with other developers on a large application, in that they can prevent multiple developers from modifying the same component at the same time. You can make sure you are working with the latest version of a component or object by synchronizing the copy of the object you are working on with the last version of the object checked into the source control system.
Why use a source control system
Most source control systems provide disaster recovery protection and functions to help manage complex development processes. With a source control system, you can track the development history of objects in your PowerBuilder workspace, maintain archives, and restore previous revisions of objects if necessary.
Source control interfaces
You work with a source control system through a source control interface in the following ways.
-
PowerBuilder supports working with Subversion (SVN) and Git source control systems through proprietary interfaces provided by source control vendors in the PowerBuilder IDE.
-
PowerBuilder also provides a standard application programming interface to any source control interfaces based on the Microsoft Common Source Code Control Interface Specification, Version 0.99.0823, which means, you can use the PowerBuilder SCC API with any source control system that implements features defined in the Microsoft specification.
-
PowerBuilder also provides a basic check in/check out utility (PBNative) that installs with the product.
PowerBuilder institutes source control at the object level. This gives you a finer grain of control than if you copied your PBLs directly to source control outside of the PowerBuilder SCC API.
PowerBuilder provides native interface options of SVN and Git for directly performing source control operations and functions in the PowerBuilder IDE. After you have configured the connection settings for SVN or Git in your PowerBuilder workspace, you can directly perform the following source control functions by right-clicking the objects in the system tree. The menu item name varies depending on the source control system (SVN or Git) you selected for your current workspace.
Supported SVN and Git version and protocol
The SVN feature has been fully tested against SVN server 1.7.1 and later.
The Git feature has been fully tested against GitHub, and also tested with GitLab, Bitbucket, Bonobo, Perforce, and Team Foundation Server (TFS).
The SVN/Git client that has been fully tested to work is: SVN client 1.9.7 and later, and Git client 2.0 and later.
The protocol of SVN/Git that has been fully tested to work is: HTTP and HTTPS.
PowerBuilder supports TLS 1.1/1.2 for the Git server handshake.
Note
If you use Git repositories to host and collaborate on your code using Team Foundation Server (TFS) or Azure DevOps Server, it is unsupported to connect to your Git repositories through SSH. Please use the recommended Personal Access Token (PAT) approach, where you use your PAT as both your username and password in PowerBuilder for Git connection.
|
Source control system |
Menus available in PowerBuilder IDE |
Used in operations |
|---|---|---|
|
SVN |
Connect to Workspace |
Connects with the SVN source control server and the project, and downloads the project to the workspace. See the section called “Get a workspace from SVN” for details. |
|
Add to Source Control |
Connects with the SVN source control server and uploads the workspace to the source control server. See the section called “Add a workspace to SVN” for details. |
|
|
SVN Commit |
Adds an object to the SVN source control server if the object does not exist on the server, or commit the changes to the server if the object has already been added to the server, or delete the object from the server if the local copy has already been deleted. See the section called “Commit objects to SVN” for details. |
|
|
SVN Update |
Gets the object from the SVN source control server if the object does not exist on the local machine, or update the local copy if the object already exists on the local machine. See the section called “Get objects from SVN” for details. |
|
|
SVN Resolve |
Removes the conflicted state of the local copy and commit it again. You will have to manually resolve the conflicts before using this menu. See the section called “Resolve conflicts” for details. |
|
|
SVN Revert |
Undoes any changes to the local copy and restores to the version on the source control server. See the section called “Revert changes” for details. |
|
|
SVN Get/Release Lock |
Locks the object in the SVN source control server so that other users cannot commit changes to the object. See the section called “Lock objects” for details. |
|
|
SVN Diff |
Compare an object in your local directory with the version of the object that was last synchronized with the source control server. See the section called “Compare objects” for details. |
|
|
SVN Show Log |
Displays the revision logs that are input during commit. See the section called “Tools for Show Log\Edit Conflicts” for details. |
|
|
Refresh |
Reloads the object if it is changed outside of IDE or after the PBL is downloaded. See the section called “Refresh objects” for details. |
|
|
Upload PBL |
Upload PBL is only necessary in the scenarios described in the section called “Upload PBL”. |
|
|
Open Containing Folder |
Opens the folder that contains the object. |
|
|
Git |
Connect to Workspace |
Connects with the Git source control server and the project, and downloads the project to the workspace. See the section called “Get a workspace from Git” for details. |
|
Add to Source Control |
Connects with the Git source control server and uploads the workspace to the source control server. See the section called “Add a workspace to Git” for details. |
|
|
Git Commit |
Adds an object to the local repository if the object does not exist on the local repository, or commit the changes to the local repository if the object has already been added to the local repository, or delete the object from the local repository if the local copy has already been deleted. See the section called “Commit objects to Git” for details. |
|
|
Git Push |
Commits the objects from the local repository to the remote repository on the source control server. See the section called “Commit objects to Git” for details. |
|
|
Git Pull |
Gets the object from the Git source control server if the object does not exist on the local repository, or update the local copy if the object already exists on the local repository. See the section called “Get objects from Git” for details. |
|
|
Git Revert |
Undoes any changes to the local copy and restores to the version on the source control server. See the section called “Revert changes” for details. |
|
|
Git Resolve |
Removes the conflicted state of the local copy and commit it again. You will have to manually resolve the conflicts before using this menu. See the section called “Resolve conflicts” for details. |
|
|
Git Diff |
Compare an object in your local directory with the version of the object that was last synchronized with the source control server. See the section called “Compare objects” for details. |
|
|
Git Show Log |
Displays the revision logs that are input during commit. See the section called “Tools for Show Log\Edit Conflicts” for details. |
|
|
Refresh |
Reloads the object if it is changed outside of IDE or after the PBL is downloaded. See the section called “Refresh objects” for details. |
|
|
Git Create Branch |
Creates a branch after the workspace is added to the source control server. See the section called “Use branches” for details. |
|
|
Git Switch Branch |
Switches to a branch. See the section called “Use branches” for details. |
|
|
Upload PBL |
Upload PBL is only necessary in the scenarios described in the section called “Upload PBL”. |
|
|
Open Containing Folder |
Opens the folder that contains the object. |
The PowerBuilder SCC API works with the source control system to perform certain source control operations and functions. Other source control operations must be performed directly from the source control management tool. After you have defined a source control connection profile for your PowerBuilder workspace, you can open the source control manager from the Library painter.
To start the source control manager from PowerBuilder
-
Select Entry>Source Control>Run Source Control Manager from the Library painter menu bar.
The menu item name varies depending on the source control system you selected in the source control connection profile for your current workspace. There is no manager tool for the PBNative check in/check out utility.
For information on configuring a source control connection profile, see Setting up a connection profile.
Which tool to use
The following table shows which source control functions you should perform from the source control manager and which you can perform from PowerBuilder:
Tool or interface
Use for this source control functionality
Source control manager
Setting up a project*
Assigning access permissions
Retrieving earlier revisions of objects*
Assigning revision labels*
Running reports*
PowerBuilder SCC API
Setting up a connection profile
Viewing the status of source-controlled objects
Adding objects to source control
Checking objects out from source control
Checking objects in to source control
Clearing the checked-out status of objects
Synchronizing objects with the source control server
Refreshing the status of objects
Comparing local objects with source control versions
* You can perform these source control operations from PowerBuilder for some source control systems.
PowerBuilder also provides minimal in-the-box source control through the PBNative check in/check out utility. PBNative allows you to lock the current version of PowerBuilder objects and prevents others from checking out these objects while you are working on them. It provides minimal versioning functionality, and does not allow you to add comments or labels to objects that you add or check in to the PBNative project directory.
Connecting to PBNative
You connect to PBNative from PowerBuilder through the PowerBuilder SCC API. You use the pop-up menu items to add, check out, check in, or get the latest version of objects on the source control server. However, any menu item that calls a source control management tool is unavailable when you select PBNative as your source control system.
Because there is no separate management tool for PBNative, if you need to edit project PBG files that get out of sync, you can open them directly on the server without checking them out of source control.
For more information about PBG files, see Editing the PBG file for a source-controlled target.
PRP files
PBNative creates files with an extra PRP extension for every object registered in the server storage location. If an object with the same file name (minus the additional extension) has been checked out, a PRP file provides the user name of the person who has placed a lock on the object. PRP files are created on the server, not in the local path.
PowerBuilder also adds a version number to the PRP file for an object in the PBNative archive directory when you register that object with PBNative source control. PowerBuilder increments the version number when you check in a new revision. The version number is visible in the Show History dialog box that you open from the pop-up menu for the object, or in the Library painter when you display the object version numbers.
For more information on the Show History dialog box, see Displaying the source control version history. For information on displaying the version number in the Library painter, see Controlling columns that display in the List view.
Using Show Differences functionality with PBNative
PBNative has an option that allows you to see differences between an object on the server and an object on the local computer using a 32-bit visual difference utility that you must install separately. For information on setting up a visual difference utility for use with PBNative, see Comparing local objects with source control versions.
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 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:
-
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.
Status determination by version number
PowerBuilder provides third-party SCC providers with an extension to the SCC API that allows them to enhance the integration of their products with PowerBuilder. Typically, calls to the SccDiff method are required to determine if an object is out of sync with the SCC repository. (This is not appropriate for Perforce or ClearCase.)
However, SCC providers can implement SccQueryInfoEx as a primary file comparison method instead of SccDiff. The SccQueryInfoEx method returns the most recent version number for each object requested. This allows PowerBuilder to compare the version number associated with the object in the PBL with the version number of the tip revision in the SCC repository in order to determine whether an object is in sync.
Since SccQueryInfoEx is a much simpler request than SccDiff, the performance of the PowerBuilder IDE improves noticeably when this feature is implemented by the SCC provider. For these providers, the SccDiff call is used as a backup strategy only when a version number is not returned on an object in the repository. Also for these providers, the version number for registered files can be displayed in the Library painter.
For more information on viewing the version number, see Controlling columns that display in the List view.
Once the new API method is implemented in an SCC provider DLL and exported, PowerBuilder automatically begins to use the SCCQueryInfoEx call with that provider. The SccQueryInfoEx method is currently used by PBNative.
Overriding the version number
For source control systems that support the SccQueryInfoEx method, you can manually override the version number of local files, but only for PowerScript objects, and only when you are connected to source control.
This can be useful with source control systems that allow you to check out a version of an object that is not the tip revision. However, the source control system alone decides the version number of the tip revision when you check a file back into source control. It is the version returned by the source control system that gets added to the PBC file for the workspace and to the PBLs in the local directory.
For more information about the PBC file, see Working in offline mode.
You change the local version number for a source-controlled PowerScript object in its Properties dialog box, which you access from the object's pop-up menu in the System Tree or the Library painter. If the source control system for the workspace supports the SccQueryInfoEx method and you are connected to source control, the Properties dialog box for a source-controlled PowerScript object (other than a PBT) has an editable SCC Version text box. The SCC Version text box is grayed if the source control system does not support the SccQueryInfoEx method or if you are not connected to source control.
Local change only
The version number that you manually enter for an object is discarded on check-in. Only the source control provider decides what number the tip revision is assigned.
You can add a PowerBuilder workspace to the SVN source control system from the PowerBuilder IDE. Make sure all of your source code for the workspace is located under the same directory as the workspace (*.pbw) file or under its sub-directory.
To add a PowerBuilder workspace to the SVN source control system:
-
Right-click the workspace in the System Tree and select Add to Source Control from the pop-up menu.
-
In the Add to Source Control dialog box, select Subversion (SVN) as the source control provider for the current workspace and click OK.
-
In the SVN Login dialog box, input the information required by the source control system. If the login information has been input before, they will be filled in automatically.
Input the URL of the SVN source control repository. The name of the current workspace is automatically displayed and a folder will be created with this name for storing this workspace on the server. Notice that the URL for the workspace will be the server repository URL + the workspace folder name. Use this complete URL when downloading the workspace.
Select an authentication type. Token is not supported for SVN currently.
Type in your user name and password for the SVN source control system.
Click Test Connection to make sure connection is successful and then click OK.
Specify the encoding format for the source code files in "ws_objects". You can select from: ANSI/DBCS, HEXASCII, and UTF8.
After connecting with the source control system successfully, the Add to Source Control dialog box displays listing all the files for the workspace that are not currently under source control. You cannot add files that are already under source control.
A "ws_objects" folder is automatically created under the workspace, for managing the source code file of the PowerBuilder objects including .srw (for window), .srm (for menu), .sru (for user object), .srd (for DataWindow), etc. The "ws_objects" folder must be added to source code, in order to manage the source code at object level.
All of the source code for the workspace must be located under the same directory as the workspace (*.pbw) file or under its sub-directory.
-
In the Add to Source Control dialog box, select the files and folders (especially "ws_objects") and click OK.
PowerBuilder starts uploading the selected files and folders to the source control system. After the file or folder is added to source control, the object in the PowerBuilder System Tree will be marked with a green dot (
) in front of it, indicating that its source
code file on the local computer is in sync with the file on the
server.
If using proxy server
If using the proxy server, configure the proxy server IP address and port number in the PB.ini file (by default, the INI file is located in C:\Users\[username]\appdata\local\appeon\powerbuilder [version]\ in Windows 8.1 or later). Copy the following section to the INI file and set the appropriate value for the proxy server:
[SourceControlProxy]
Url=192.0.0.88
Port=80
Username=
Password=
Timeout=10
When PowerBuilder IDE opens without loading any workspace, you can get a PowerBuilder workspace from the source control system and open the workspace in the PowerBuilder IDE directly.
To get a PowerBuilder workspace from the SVN source control system:
-
Right-click "No Workspace" in the System Tree and select Connect to Workspace from the pop-up menu
or
Select Connect to Workspace from the File menu.
The Connect to Workspace dialog box displays. If the login information has been input before, they will be filled in automatically.
-
Select Subversion (SVN) from the Source Control System list.
Input the repository URL of the workspace. Notice that the complete URL should be the server repository URL + the workspace folder name.
Type in the name of the workspace file to be downloaded.
Select an authentication type. Token is not supported for SVN currently.
Type in your user name and password for the SVN source control system.
Type or select a path for the local root directory in the "Checkout Directory" box. All the files that you add to or get from source control must reside in this path or in a subdirectory of this path.
Select the "Refresh all PBLs with the source code after download" option to refresh all PBLs after downloading the source code from workspace if you are unsure whether the PBLs are updated with the latest source code.
-
Click Test Connection, and click OK when connection is successful.
PowerBuilder starts downloading the workspace from the SVN source control system, and after the workspace is successfully downloaded, it will be loaded in the PowerBuilder IDE automatically.
Note
After you get a workspace which was added to SVN using a third-party tool such as TortoiseSVN (not by PowerBuilder IDE), the objects will be marked with this icon
which means the objects are not yet under
source control in PowerBuilder IDE, so you should commit the
entire workspace from the PowerBuilder IDE to SVN to add it
under source control.
After you create a new object or change an existing object on your local workspace, you can commit the object to the SVN source control system so that other developers can reach it.
To commit an object to the SVN source control system:
-
Right-click the object (or the library that contains the object) in the System Tree and select SVN Commit from the pop-up menu.
-
In the commit dialog box that displays, input a comment and click OK to confirm committing the object.
PowerBuilder starts uploading the object to the SVN source control system. After the object is uploaded successfully, the icon in front of the object will change from a plus sign (
) to a green dot (), indicating that the object on the local
computer is in sync with the object on the server.
If conflicts are detected, you will be prompted in the output view and will have to resolve the conflict manually. See the section called “Resolve conflicts” for details.
If you remove an object from your local workspace, you use the same instructions as above to commit the change and remove the object from the SVN source control server.
Note
If you are prompted for conflicts when committing a removed object, you should first restore the object using the Revert feature of an SVN client (such as TortoiseSVN), and then remove the local object and execute SVN Commit again.
The output (including error and warning) of a variety of operations (SVN Commit, SVN Update, SVN Revert, Refresh etc.) displays in the Output window. Currently, lines in the Output window provide no links to open the object when you double-click on that line, and although the pop-up menu provides the options Edit and Edit Source, they will not open an object in a painter or the Source editor.
For objects that are changed or added by other developers to the SVN source control server but not yet synchronized to your local workspace, you can get these objects from the SVN source control system.
To get objects from the SVN source control system:
-
Right-click the library (or the workspace or the target that contains the object to be downloaded) in the System Tree and select SVN Update from the pop-up menu.
PowerBuilder starts downloading the new objects or changed objects from the SVN source control system to the local workspace. After the object is downloaded successfully, the object will be marked with a green dot (
) in front of it, indicating that the object
on the local computer is in sync with the object on the
server.
If conflicts are detected, you will be prompted in the output view and will have to resolve the conflict using an SVN client. See the section called “Resolve conflicts” for details.
When "Compile failure" error occurs
When "Compile failure" error occurs during the download process, clicking OK will still download and import the object with the error (and you will need to fix the error later), or clicking Cancel will terminate the download process of all objects and revert back to the object on the local computer.
When to do a full build
When the following problems happen, a full build may help to fix them:
-
If both the parent object and the child object have been changed on the source control server, the parent object or the child object may not display correctly after downloaded from the server to the local computer.
-
After the object is downloaded from the server to the local computer, PowerBuilder IDE crashed when trying to open the object.
-
After the object is downloaded from the server to the local computer, the application crashed when running from the PowerBuilder IDE.
-
When the following error occurs: "Open of User Object xxx failed. It has been migrated to current version format, but must also be successfully regenerated.", perform a full build can resolve the error.
-
If more than one developer are making changes to the same object
and committing the object at the same time, conflicts will occur when
synchronizing the object. When conflicts are detected, the object in
the library tree will be marked by a "!" sign (
) and you will be prompted in the output view
and will have to resolve the conflict manually.
Note
If the workspace has already been added to the SVN source code system in PowerBuilder 2017 R2, please remove its binary property first before resolving conflicts in PowerBuilder 2017 R3 and later. See Remove the binary property from a R3 source-controlled workspace for details.
The following steps walk you through how to resolve the conflicts and merge the changes (Suppose developer A and B make changes to the same PowerBuilder object at the same time):
Step 1: Developer A commits the object to the source control server successfully.
Step 2: When developer B tries to commit the object, he receives
a message requiring him to update the object first, so developer B
performs SVN Update, then the object in the library tree will be
marked by a "!" sign () which means there is a conflict, and the
changes made by Developer B, the original code, and the changes made
by Developer A will be listed together in the object's source
code.
Step 3: Developer B right-clicks the object and selects Edit Conflicts; the object's source code will be displayed in TortoiseSVN. Developer B looks into the source code and decides which changes to keep (the changes made by Developer B, the original code, or the changes made by Developer A). He manually removes the unwanted changes from the object's source code.
In order for the "Edit Conflicts" option to work, developers will need to specify the executable program of TortoiseSVN in the Properties of Workspace dialog box first. See Tools for Show Log\Edit Conflicts for details.
Note
After you merge the changes, make sure to refresh and then compile the object in PowerBuilder, otherwise, the object may be missing or fail to open in the PowerBuilder IDE, or may cause the PowerBuilder IDE to crash.
Step 4: Developer B performs SVN Resolve for the object to refresh the object status (clears the conflict sign) and commit the object to the server.
A workspace that has already been added to the SVN source code system from PowerBuilder 2017 R2 must have its (as well as all files') binary property removed, in order to correctly resolve conflicts and merge changes in PowerBuilder 2017 R3 and later.
To remove the binary property of the files for a workspace:
-
In PowerBuilder IDE, get the workspace from the SVN source control system.
-
Download the SccAuxiliaryTool.exe tool from the Appeon website.
-
Execute the following command to remove the binary property of the files for this workspace:
SccAuxiliaryTool.exe /command:svn_prop_del /path:C:\check_out\svn\workspace_1
The /path parameter should point to the directory where the workspace is located.
-
Commit the changed files to the source control system.
For objects that are changed locally but not yet synchronized to the SVN source control system, you can give up the local changes and restore to the version in the source control system.
To revert objects from the SVN source control system:
-
Right-click the workspace, target, library, or object in the System Tree and select SVN Revert from the pop-up menu.
-
Select the objects you want to revert and then click OK.
PowerBuilder downloads the object from the SVN source control system and replaces the copy in the local workspace.
After the object is loaded into the PowerBuilder IDE, it might be changed outside of the PowerBuilder IDE, for example, the developer merges the changes from the other version using an SVN client, and such changes will not be detected by the PowerBuilder IDE, you will need to right click the object and select Refresh from the pop-up menu to reload the object in the PowerBuilder IDE.
The "Refresh" menu is also used when the PBL file on the source control server is not the latest when you first download the entire workspace from the source control server. In such case, after you download the PBL file, you will need to select the Refresh menu to refresh the objects and reload the latest objects in the PowerBuilder IDE.
The "Upload PBL" menu should be used with caution.
The PBL file will be automatically uploaded to the source code server when the workspace is first added to source control, and the PBL file will be automatically downloaded when the workspace is first downloaded from source control to a local machine. After that, it will not be uploaded or downloaded again whenever new or changed objects are uploaded or downloaded. Instead, the PBL file on the local machine will be automatically updated whenever objects are created or changed.
The "Upload PBL" menu should be used only when you need to separately upload the PBL file to the source control server, in scenarios like you add a new PBL to the workspace and the PBL has not been uploaded to the source control server before, or the PBL file is removed from the workspace, or the PBL file has been changed dramatically since it is first uploaded, or the PBL file has been set with the "svn:needs-lock" property, or the workspace is compiled with related errors. In any other circumstances, it is not recommended to manipulate (including get, commit, lock etc.) the PBL file in the source control system using any tool.
The Upload PBL dialog will list and select the newly added PBL file, but will not select the modified PBL file.
When you lock the local object, the object on the source control server will be locked correspondingly. Locking the object can prevent the other users committing changes to them.
You can lock PBW, PBT, and source files of PBLs; but cannot lock PBD, or PBX files.
To lock objects in the SVN source control system:
-
Right-click the workspace, target, library, or object in the System Tree and select SVN Get Lock from the pop-up menu.
-
Select the files or objects you want to lock and then click OK.
If newer version of the file/object exists on the source code server, you will be prompted to update the file/object first before locking it. You can select to update the selected files/objects to the latest version and then lock the file, or cancel the update and lock procedure.
When PowerBuilder locks the file or object in the SVN source control system successfully, it adds the "SVN Release Lock" option to the pop-up menu.
Note
When the PBL file is made read-only by setting the "svn:needs-lock" property via a third-party tool, the PBL file will be available for selection in the SVN Get Lock dialog; and when you select to lock the PBL file, the local copy of the PBL file is made editable; and when you release the lock for the PBL file, the local copy of the PBL file is made read-only again. The server copy of the PBL file will remain intact during Get/Release Lock, because the PBL file should never be manipulated in the source control server except for scenarios in Upload PBL.
To unlock objects in the SVN source control system:
-
Right-click the workspace, target, library, or object in the System Tree and select SVN Release Lock from the pop-up menu.
-
Select the files or objects you want to unlock and then click OK.
PowerBuilder unlocks the file or object in the SVN source control system so that other users can commit changes to them.
The file or object will be automatically unlocked when you commit the file or object to the server by performing SVN Commit, unless you select the "Keep locks" option in the SVN Commit dialog box.
svn:needs-lock property
To make it easier to manage locks, there is a new property called "svn:needs-lock". PowerBuilder IDE provides no direct option for setting this property; you can set this property using an SVN client (such as TortoiseSVN). After that, you can manipulate (such as lock, commit etc.) the object which has the svn:needs-lock property using the SVN options provided in the PowerBuilder IDE.
If you set "svn:needs-lock" to an object, you should also set "svn:needs-lock" to the PBL file that contains this object, otherwise changes made to the object may not be properly saved and synchronized between the object source and the PBL file. For example, if you set "svn:needs-lock" to the object only but not to the PBL file, and then if you edit the object without locking the object first, the changes you made to the object will not be saved to the object source (which is expected), but will be saved in the object painter (which is not expected); in such case, you should refresh the object (using the SVN Refresh option) to discard the changes from the object painter.
Note
After you set the "svn:needs-lock" property to an object, you should commit the object (using the Commit option in the SVN client, or using the SVN Commit option in PowerBuilder) to make the property effective; so after that any user who wants to edit the object will need to lock the object first.
However, it is a different case for the PBL file. After you set the "svn:needs-lock" property to the PBL file, you should commit the PBL file (using the Commit option in the SVN client) or upload the PBL file (using the Upload PBL option in PowerBuilder) to make the property effective; and after that when the user tries to "lock" or "unlock" the PBL file, only the local copy is locked or unlocked (the local copy is changed from read-only to editable when locked; and changed from editable to read-only when unlocked), the server copy of the PBL file has no change (it cannot be locked or unlocked); therefore, unlike the object which can be locked by one user at a time, the PBL file can be "locked" by multiple users at the same time.
PowerBuilder IDE provides no utilities to view logs or edit conflicts, but it allows you to specify the executable file of TortoiseSVN and use it to view logs and edit conflicts.
To specify the executable file of TortoiseSVN:
-
Right-click the workspace in the System Tree and select Properties from the pop-up menu.
-
In the Properties of Workspace dialog box, select the Source Control tab, and then click the Advanced button.
-
In the Source Control Advanced Settings dialog box, select Show Log/Edit Conflicts in the left panel, and then specify the executable program of TortoiseSVN.
-
Click OK.
To show the revision log:
-
Right-click the workspace, target, library, or object in the System Tree and select SVN Show Log from the pop-up menu.
The TortoiseSVN tool displays the revision logs directly.
To edit conflicts:
-
Right-click the object with the conflict sign (
) in the System Tree and select SVN Edit
Conflicts from the pop-up menu.
The TortoiseSVN tool displays the source control with the conflicts. For more details, see Resolve conflicts.
You can compare an object in your local directory with the version of the object that was last synchronized with the source control server. If the object you want to compare has not been added to the source control server, or the local object is not changed since last sync, the SVN Diff menu item is not available.
PowerBuilder IDE provides no difference utility, but it allows you to select one that you have already installed. Please make sure the utility itself is compatible with SVN client 1.9.7 or later. The recommended utilities and versions are:
-
TortoiseSVN 1.9.7
-
Araxis Merge 2018.4988
-
Beyond Compare 4.2.4
-
DiffMerge 4.2.0
-
ExamDiff Pro 9.0.1.8
-
KDiff3 0.9.98
-
SemanticMerge 2.0.120.0
-
UltraCompare 18.00.0.47
-
WinMerge 2.14.0.0
To select a utility for object comparison:
-
Right-click the workspace in the System Tree and select Properties from the pop-up menu.
-
In the Properties of Workspace dialog box, select the Source Control tab, and then click the Advanced button.
-
In the Source Control Advanced Settings dialog box, select Diff Viewer in the left panel, then select the tool name from the list, specify the executable program of the tool, and change the arguments if necessary.
-
Click OK.
Method 1: To compare the local object with the version last sync with source control:
-
Right-click the object in the System Tree and select SVN Diff from the pop-up menu.
The difference utility displays the objects and highlights the differences directly.
Method 2: To compare the local object with the version last sync with source control:
-
Right-click the object in the System Tree and select SVN Commit (Release Lock, Revert, or Resolve) from the pop-up menu.
-
In the SVN Commit (Release Lock, Revert, or Resolve) dialog, double click an item from the object list to view the differences.
You can view the differences of the item which is added, modified, locked, conflicted, or deleted.
The difference utility displays the objects and highlights the differences directly.
You can also compare the workspace file (.pbw) or the target file (.pbt), but you cannot compare the binary file such as the library file (.pbl).
After you add the workspace to SVN using the Add to Source Control menu or get the workspace from SVN using the Connect to Workspace menu, you can view and edit the SVN connection settings in the Properties of Workspace dialog box; you can also remove and restore the connection between the workspace and the source control server.
To view/edit the connection settings of the SVN source control system:
-
Right-click the workspace in the System Tree and select Properties from the pop-up menu.
-
Select the Source Control tab in the Properties of Workspace dialog box.
-
Select Subversion (SVN) from the Source Control System list.
Subversion (SVN) is available from the list when the current workspace is under the SVN source control, for example, after the workspace is uploaded to SVN using the Add to Source Control menu (see the section called “Add a workspace to SVN”), or after the workspace is downloaded from SVN using the Connect to Workspace menu (see the section called “Get a workspace from SVN”), or when PowerBuilder IDE detects that an .svn sub-folder exists.
-
View or edit the connection settings for the selected source control system. Note that User ID and Password are used by all workspaces, but the other settings are not.
User ID and Password: User credentials for logging into the source control system. These settings can be changed here. Token is not supported for SVN currently.
Repository URL: A URL that points to the repository on the source control server. This setting is read-only and cannot be changed here.
Local Root Directory: A local path where all the files that you add to or get from source control must reside. This setting is read-only and cannot be changed here.
-
Click OK.
To remove/restore the connection settings from the SVN source control system:
-
If you select None from the Source Control System list and click OK, PowerBuilder will remove the connection between the workspace and the source control server.
-
If you move the workspace to a new location and then select SVN from the Source Control System list and click OK, PowerBuilder will restore connections between the workspace and the source control server.
Besides that, if a workspace is under source control using a third-party tool such as TortoiseSVN, you can open the workspace (make sure the .svn sub-folder exists) and then select SVN from the Source Control System list to establish connections between the workspace and the source control server in the PowerBuilder IDE. Notice that the objects are marked with this icon
which means the objects are not yet under
source control in PowerBuilder IDE, so you should commit the
entire workspace to add it under source control, and so the
"ws_objects" folder is successfully created and uploaded to SVN.
The "ws_objects" folder is essential for correctly identifying the
status of the PowerBuilder objects during the source control
management process.
After a workspace is successfully added to the SVN source control, icons in the PowerBuilder System Tree display the source control status of all objects in the workspace.
The icons and their meanings are described in the following tables.
|
Icon |
SVN source control status of object displaying icon |
|---|---|
|
|
The object resides only locally and is not under source control. |
|
|
The object is under source control. The object on the local computer is in sync with the object on the server. |
|
|
The object is under source control. The object on the local computer is changed, and is not committed to the server. |
|
|
The object is under source control. The object on the local computer conflicts with the object on the server. |
|
|
The object is under source control, and the object is locked. |
If your local PowerBuilder workspace has not been added to the Git source control system before, you can add the entire workspace to Git from the PowerBuilder IDE. To add a workspace to Git, you do it in two steps:
Step 1: You upload the workspace to the repository on your local computer.
Step 2: You push the workspace from the local repository to the remote repository on the Git source control server.
Below are the complete steps.
To add a PowerBuilder workspace to the Git source control system:
-
Right-click the workspace in the System Tree and select Add to Source Control from the pop-up menu.
-
In the Add to Source Control dialog box, select Git as the source control provider for the current workspace and click OK.
-
In the Author Information dialog box, input the author name and author email.
Specify the encoding format for the source code files in "ws_objects". You can select from: ANSI/DBCS, HEXASCII, and UTF8.
After clicking OK, the Add to Source Control dialog box displays listing all the files for the workspace that are not currently under source control. You cannot add files that are already under source control.
A "ws_objects" sub-folder is automatically created under the workspace, for managing the source code file of the PowerBuilder objects including .srw (for window), .srm (for menu), .sru (for user object), .srd (for DataWindow), etc. The "ws_objects" folder must be added to the source code, in order to manage the source code at object level.
-
In the Add to Source Control dialog box, select the files and folders (especially ws_objects) and click OK.
PowerBuilder adds the selected files and folders to the repository on your local computer. After the file or folder is added to the local repository, the object in the PowerBuilder System Tree will be marked with a green dot (
) in front of it, indicating that its source
code file on the local computer is in sync with the file on the
local repository. Now you can proceed to push the objects from the
local repository to the remote repository on the Git source
control server.
-
Right-click the workspace in the System Tree and select Git Push from the pop-up menu.
-
In the Git Login dialog box, input the information required by the source control system. If the login information has been input before, they will be filled in automatically.
Input the URL of the Git server and the repository for the workspace. Make sure the repository with the same name exists on the server and the repository is empty before you push the files.
The name of the current workspace is automatically displayed.
Select an authentication type: basic or token.
Type in your user name and password (or token) for the Git source control system.
Click Test Connection to make sure connection is successful and then click OK.
If using proxy server
If using the proxy server, configure the proxy server IP address and port number in the PB.ini file (by default, the INI file is located in C:\Users\[username]\appdata\local\appeon\powerbuilder [version]\ in Windows 8.1 or later). Copy the following section to the INI file and set the appropriate value for the proxy server:
[SourceControlProxy]
Url=192.0.0.88
Port=80
Username=
Password=
Timeout=10
PowerBuilder pushes the selected objects to the Git source control system.
"Reference was not fast-forwardable" error when pushing to Bitbucket
When adding the workspace to the Bitbucket server using "Git Push", you may come across the "Reference was not fast-forwardable" error, if the repository on the Bitbucket server is created with a readme (the "Include a README" option set to "Yes, ..."). To resolve this error, you can first execute a "Git Pull" (to synchronize the server repository with the local repository) and then execute "Git Push" again.
When PowerBuilder IDE opens without loading any workspace, you can get a PowerBuilder workspace from the source control system and open the workspace in the PowerBuilder IDE directly.
To get a PowerBuilder workspace from the Git source control system:
-
Right-click "No Workspace" in the System Tree and select Connect to Workspace from the pop-up menu
or
Select Connect to Workspace from the File menu.
The Connect to Workspace dialog box displays. If the login information has been input before, they will be filled in automatically.
-
Select Git from the Source Control System list.
Input the URL of the Git source control server and the name of an existing repository on the server.
Select an authentication type: basic or token.
Type in your user name and password (or token) for the Git source control system.
Type or select a path for the local root directory in the "Checkout Directory" box. All the files that you add to or get from source control must reside in this path or in a subdirectory of this path.
Input the author name and author email.
Select the "Refresh all PBLs with the source code after download" option to refresh all PBLs after downloading the source code from workspace if you are unsure whether the PBLs are updated with the latest source code.
If using proxy server
If using the proxy server, configure the proxy server IP address and port number in the PB.ini file (by default, the INI file is located in C:\Users\[username]\appdata\local\appeon\powerbuilder [version]\ in Windows 8.1 or later). Copy the following section to the INI file and set the appropriate value for the proxy server:
[SourceControlProxy]
Url=192.0.0.88
Port=80
Username=
Password=
Timeout=10
-
Click Test Connection, and click OK when connection is successful.
PowerBuilder starts downloading the workspace from the Git source control system, and after the workspace is successfully downloaded, it will be loaded in the PowerBuilder IDE automatically.
Note
After you get a workspace which was added to Git using a third-party tool such as TortoiseGit (not by PowerBuilder IDE), the objects will be marked with this icon
which means the objects are not yet under
source control in PowerBuilder IDE, so you should commit the
entire workspace from the PowerBuilder IDE to Git to add it
under source control.
After you create a new object or change an existing object on your local workspace, you can commit the object to the Git source control system so that other developers can reach it. Similar to how you add a workspace to Git, you commit the object in two steps: 1) upload the object to the local repository; 2) push the object from the local repository to the server repository.
Note that if conflicts are detected, make sure you resolve the conflict before committing the object.
To commit an object to the Git source control system:
-
Right-click the object (or the library that contains the object) in the System Tree and select Git Commit from the pop-up menu.
-
In the commit dialog box that displays, input a comment and click OK to confirm committing the object.
PowerBuilder uploads the object to the repository on the local computer. After the object is uploaded successfully, the icon in front of the object will change from a plus sign (
) to a green dot (), indicating that the object on the local
computer is in sync with the object on the local repository.
Note that if you have only
committed some (not all) of the objects, performing Refresh may
remove the uncommitted objects.
Now you can proceed to push the objects from the local repository to the server repository.
To push objects to the server repository, you can only push from the workspace, as described in the next step.
-
Right-click the workspace in the System Tree and select Git Push from the pop-up menu.
PowerBuilder pushes the new or changed objects from the local repository to the server repository.
If conflicts are detected, you will be prompted in the output view and will have to resolve the conflict manually before you can push the object to the server repository. See the section called “Resolve conflicts” for details.
If you remove an object from your local workspace, you use the same instructions as above to commit the change and remove the object from the Git source control server.
The output (including error and warning) of a variety of operations (Git Commit, Git Pull, Git Revert, and Refresh) displays in the Output window. Currently, lines in the Output window provide no links to open the object when you double-click on that line, and although the pop-up menu provides the options Edit and Edit Source, they will not open an object in a painter or the Source editor.
For objects that are changed or added by other developers to the Git source control server but not yet synchronized to your local workspace, you can get these objects from the source control system.
PowerBuilder IDE will add the autocrlf option and set it to true on Windows if no other Git tool has installed and configured such an option. However, if you manually change the setting of autocrlf (from true to false or input), and then download objects from the server, these objects will have LF line endings instead of CRLF, which will cause compilation errors in the PowerBuilder IDE. If such compilation error occurs, you should set autocrlf to true, download files from the server again, and then compile again. For more about the autocrlf option, refer to https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration.
To get objects from the Git source control system:
-
Right-click the workspace (that contains the object to be downloaded) in the System Tree and select Git Pull from the pop-up menu.
Git Pull menu is only available at the workspace level, and is not available at the target or library levels.
PowerBuilder starts downloading the new objects or changed objects from the Git source control system to the local workspace. After the object is downloaded successfully, the object will be marked with a green dot (
) in front of it, indicating that the object
on the local computer is in sync with the object on the
server.
If conflicts are detected, you will be prompted in the output view and will have to resolve the conflict using a Git client. See the section called “Resolve conflicts” for details.
When "Compile failure" error occurs
When "Compile failure" error occurs during the download process, clicking OK will still download and import the object with the error (and you will need to fix the error later), or clicking Cancel will terminate the download process of all objects and revert back to the object on the local computer.
When to do a full build
When the following problems happen, a full build may help to fix them:
-
If both the parent object and the child object have been changed on the source control server, the parent object or the child object may not display correctly after downloaded from the server to the local computer.
-
After the object is downloaded from the server to the local computer, PowerBuilder IDE crashed when trying to open the object.
-
After the object is downloaded from the server to the local computer, the application crashed when running from the PowerBuilder IDE.
-
If more than one developer are making changes to the same object
and committing the object at the same time, conflicts will occur when
synchronizing the object. When conflicts are detected, the object in
the library tree will be marked by a "!" sign () and you will be prompted in the output view
and will have to resolve the conflict manually before you can commit
the object.
The following steps walk you through how to resolve the conflicts and merge the changes (Suppose developer A and B make changes to the same PowerBuilder object at the same time):
Step 1: Developer A commits the object to the source control server successfully.
Step 2: When developer B tries to commit the object, he receives
a message requiring him to update the object first, so developer B
performs Git Pull, then the object in the library tree will be marked
by a "!" sign () which means there is a conflict, and the
changes made by Developer B, the original code, and the changes made
by Developer A will be listed together in the object's source
code.
Step 3: Developer B right-clicks the object and selects Edit Conflicts; the object's source code will be displayed in TortoiseGit. Developer B looks into the source code and decides which changes to keep (the changes made by Developer B, the original code, or the changes made by Developer A). He manually removes the unwanted changes from the object's source code.
In order for the "Edit Conflicts" option to work, developers will need to specify the executable program of TortoiseGit in the Properties of Workspace dialog box first. See Tools for Show Log\Edit Conflicts for details.
Note
After you merge the changes, make sure to refresh and then compile the object in PowerBuilder, otherwise, the object may be missing or fail to open in the PowerBuilder IDE, or may cause the PowerBuilder IDE to crash.
Step 4: Developer B performs Git Resolve for the object to refresh the object status (clears the conflict sign) and commit the object to the server.
For objects that are changed locally but not yet synchronized to the Git source control system, you can give up the local changes and restore to the version in the server repository.
After the object is loaded into the PowerBuilder IDE, it might be changed outside of the PowerBuilder IDE, for example, the developer merges the changes from the other version using a Git client, and such changes will not be detected by the PowerBuilder IDE, you will need to right click the object and select Refresh from the pop-up menu to reload the object in the PowerBuilder IDE.
The "Refresh" menu is also used when the PBL file on the source control server is not the latest when you first download the entire workspace from the source control server. In such case, after you download the PBL file, you will need to select the Refresh menu to refresh the objects and reload the latest objects in the PowerBuilder IDE.
The "Upload PBL" menu should be used with caution.
The PBL file will be uploaded to the source code server automatically when the workspace is first added to source control, and the PBL file will be downloaded automatically when the workspace is first downloaded from source control to a local machine. After that, it will not need to be uploaded or downloaded again whenever new or changed objects are uploaded or downloaded. Instead, the PBL file on the local machine will be updated automatically whenever objects are created or changed.
The "Upload PBL" menu is used only when you need to separately upload the PBL file to the source control server, in scenarios like you add a new PBL to the workspace and the PBL has not been uploaded to the source control server before, or the PBL file is removed from the workspace, or the PBL file has been changed dramatically since it is first uploaded, or the workspace is compiled with related errors. In any other circumstances, it is not recommended to manipulate (including get, commit, lock etc.) the PBL file in the source control system using any tool.
The Upload PBL dialog will list and select the newly added PBL file, but will not select the modified PBL file.
PowerBuilder IDE provides no utilities to view logs or edit conflicts, but it allows you to specify the executable file of TortoiseGit and use it to view logs and edit conflicts.
To specify the executable file of TortoiseGit:
-
Right-click the workspace in the System Tree and select Properties from the pop-up menu.
-
In the Properties of Workspace dialog box, select the Source Control tab, and then click the Advanced button.
-
In the Source Control Advanced Settings dialog box, select Show Log in the left panel, and then specify the executable program of TortoiseGit.
-
Click OK.
To show the revision log:
-
Right-click the workspace, target, library, or object in the System Tree and select Git Show Log from the pop-up menu.
The TortoiseGit tool displays the revision logs directly.
To edit conflicts:
-
Right-click the object with the conflict sign (
) in the System Tree and select Git Edit
Conflicts from the pop-up menu.
The TortoiseGit tool displays the source control with the conflicts. For more details, see Resolve conflicts.
You can compare an object in your local directory with the version of the object that was last synchronized with the source control server. If the object you want to compare has not been added to the source control server, or the local object is not changed since last sync, the Git Diff menu item is not available.
PowerBuilder IDE provides no difference utility, but it allows you to select one that you have already installed. Please make sure the utility itself is compatible with Git client 2.0 or later. The recommended utilities and versions are:
-
TortoiseGit 2.6.0.0
-
Araxis Merge 2018.4988
-
Beyond Compare 4.2.4
-
DiffMerge 4.2.0
-
ExamDiff Pro 9.0.1.8
-
KDiff3 0.9.98
-
SemanticMerge 2.0.120.0
-
UltraCompare 18.00.0.47
-
WinMerge 2.14.0.0
To select a utility for object comparison:
-
Right-click the workspace in the System Tree and select Properties from the pop-up menu.
-
In the Properties of Workspace dialog box, select the Source Control tab, and then click the Advanced button.
-
In the Source Control Advanced Settings dialog box, select Diff Viewer in the left panel, then select the tool name from the list, specify the executable program of the tool, and change the arguments if necessary.
-
Click OK.
Method 1: To compare the local object with the version last sync with source control:
-
Right-click the object in the System Tree and select Git Diff from the pop-up menu.
The difference utility displays the objects directly.
Method 2: To compare the local object with the version last sync with source control:
-
Right-click the object in the System Tree and select Git Commit (Revert, or Resolve) from the pop-up menu.
-
In the Git Commit (Revert, or Resolve) dialog, double click an item from the object list to view the differences.
You can view the differences of the item which is added, modified, locked, or conflicted (but not deleted).
The difference utility displays the objects and highlights the differences directly.
You can also compare the workspace file (.pbw) by right-clicking the workspace and selecting Git Diff, or compare the target file (.pbt) by right-clicking the target and selecting Git Diff, but you cannot compare the binary file such as the library file (.pbl).
You can create a branch after the workspace is added to the Git source control.
To create a branch,
-
Right-click the workspace and select Git Create Branch from the pop-up menu.
-
In the Create Branch dialog, input the branch name you want to create, select whether to base the new branch on HEAD or a chosen branch, and click OK.
To overwrite the branch if a branch with the same name already exists, select the "Force if duplicate branch name exists" option.
The branch will be created in your local repository. You can use the Git Push menu to commit the branch to the remote repository on the server, but note that the PBL file(s) will not be uploaded to the server.
To switch to a branch,
-
Right-click the workspace and select Git Switch Branch from the pop-up menu.
-
In the Switch Branch dialog, select the branch you want to switch to and click OK.
If you switch to a remote branch (in most cases the one starting with "origin/"), you will not be able to commit changes to the remote branch.
If you get a workspace which was added to Git using a third-party tool such as TortoiseGit, you should commit the entire workspace from the PowerBuilder IDE to Git immediately after you get it; otherwise the object or changes may be lost after you switch the branch.
After you add the workspace to Git using the Add to Source Control menu or get the workspace from Git using the Connect to Workspace menu, you can view and edit the Git connection settings in the Properties of Workspace dialog box; you can also remove and restore the connection between the workspace and the source control server.
To view/edit the connection settings of the Git source control system:
-
Right-click the workspace in the System Tree and select Properties from the pop-up menu.
-
Select the Source Control tab in the Properties of Workspace dialog box.
-
Select Git from the Source Control System list.
Git is available from the list when the current workspace is under the Git source control, for example, after the workspace is uploaded to Git using the Add to Source Control menu (see the section called “Add a workspace to Git”), or after the workspace is downloaded from Git using the Connect to Workspace menu (see the section called “Get a workspace from Git”), or when PowerBuilder IDE detects that a .git sub-folder exists.
-
View or change the connection settings for the selected source control system. Note that User ID and Password are used by all workspaces, but the other settings are not.
User ID and Password/Token: User credentials for logging into the source control system. These settings can be changed here.
Repository URL: A URL that points to the repository on the source control server. This setting can be changed here.
Local Root Directory: A local path where all the files that you add to or get from source control must reside. This setting is read-only and cannot be changed here.
Author and Email: Author information that will be used when committing objects. These settings can be changed here.
-
Click OK.
To remove/restore the connection settings from the Git source control system:
-
If you select None from the Source Control System list and click OK, PowerBuilder will remove the connection between the workspace and the source control server.
-
If you move the workspace to a new location and then select Git from the Source Control System list and click OK, PowerBuilder will restore connections between the workspace and the source control server.
Besides that, if a workspace is under source control using a third-party tool such as TortoiseGit, you can open the workspace (make sure the .git sub-folder exists) and then select Git from the Source Control System list to establish connections between the workspace and the source control server in the PowerBuilder IDE. Notice that the objects are marked with this icon
which means the objects are not yet under
source control in PowerBuilder IDE, so you should commit the
entire workspace to add it under source control, and so the
"ws_objects" folder is successfully created and uploaded to Git.
The "ws_objects" folder is essential for correctly identifying the
status of the PowerBuilder objects during the source control
management process.
After a workspace is successfully added to the Git source control, icons in the PowerBuilder System Tree display the source control status of all objects in the workspace.
The icons and their meanings are described in the following tables.
|
Icon |
Git source control status of object displaying icon |
|---|---|
|
|
The object resides only locally and is not under source control. |
|
|
The object is under source control. The object on the local computer is in sync with the object on the server. |
|
|
The object is under source control. The object on the local computer is changed, and is not committed to the server. |
|
|
The object is under source control. The object on the local computer conflicts with the object on the server. |
PowerBuilder provides a direct connection to external SCC-compliant source control systems. It no longer requires you to register PowerBuilder objects in a separate work PBL before you can check them into or out of the source control system.
For information on upgrading PowerBuilder applications and objects previously checked into source control through a registered PBL, see Upgrading existing projects under source control.
Before you can perform any source control operations from PowerBuilder, you must set up a source control connection profile for your PowerBuilder workspace, either from the System Tree or from the Library painter. Even if you use the PBNative check in/check out utility, you must access source-controlled objects through an SCC interface that you define in the Workspace Properties dialog box.
The source control connection profile assigns a PowerBuilder workspace to a source control project. Setting up a source control project is usually the job of a project manager or administrator. See Project manager's tasks.
Creating a new source control project
Although you can create a project in certain source control systems directly from PowerBuilder, it is usually best to create the project from the administrative tool for your source control system before you create the connection profile in PowerBuilder.
In PowerBuilder you can set up a source control connection profile at the workspace level only. Local and advanced connection options can be defined differently on each computer for PowerBuilder workspaces that contain the same targets.
Local connection options
Local connection options allow you to create a trace log to record all source control activity for your current workspace session. You can overwrite or preserve an existing log file for each session.
You can also make sure a comment is included for every file checked into source control from your local computer. If you select this connection option, the OK button on the Check In dialog box is disabled until you type a comment for all the objects you are checking in.
The following table lists the connection options you can use for each local connection profile:
|
Select this option |
To do this |
|---|---|
|
Log All Source Management Activity (not selected by default) |
Enable trace logging. By default the log file name is PBSCC190.LOG, which is saved in your workspace directory, but you can select a different path and file name. |
|
Append To Log File (default selection when logging is enabled) |
Append source control activity information to named log file when logging is enabled. |
|
Overwrite Log File (not selected by default) |
Overwrite the named log file with source control activity of the current session when logging is enabled. |
|
Require Comments On Check In (not selected by default; not available for PBNative source control) |
Disable the OK button on the Check In dialog box until you type a comment. |
|
This Project Requires That I Sometimes Work Offline (not selected by default) |
Disable automatic connection to source control when you open the workspace. |
|
Delete PowerBuilder Generated Object Files (not selected by default) |
Remove object files (such as SRDs) from the local directory after they are checked into source control. This may increase the time it takes for PowerBuilder to refresh source control status, but it minimizes the drive space used by temporary files. You cannot select this option for the Perforce, ClearCase, or Continuus source control systems. |
|
Perform Diff On Status Update |
Permit display of out-of-sync icons for local objects that are different from objects on the source control server. Selecting this also increases the time it takes to refresh source control status. You cannot select this option for Perforce. |
|
Suppress prompts to overwrite read-only files |
Avoid message boxes warning that read-only files exist on your local project directory. |
|
Show warning when opening objects not checked out |
Avoid message boxes when opening objects that are still checked in to source control. |
|
Status Refresh Rate (5 minutes by default) |
Specifies the minimum time elapsed before PowerBuilder automatically requests information from the source control server to determine if objects are out of sync. Valid values are between 1 and 59 minutes. Status refresh rate is ignored when you are working offline. |
Advanced connection options
Advanced connection options depend on the source control system you are using to store your workspace objects. Different options exist for different source control systems.
Applicability of advanced options
Some advanced options might not be implemented or might be rendered inoperable by the PowerBuilder SCC API interface. For example, if an advanced option allows you to make local files writable after an Undo Check Out operation, PowerBuilder still creates read-only files when reverting an object to the current version in source control. (PowerBuilder might even delete these files if you selected the Delete PowerBuilder Generated Object Files option.)
To set up a connection profile
-
Right-click the Workspace object in the System Tree (or in the Tree view of the Library painter) and select Properties from the pop-up menu.
-
Select the Source Control tab from the Workspace Properties dialog box.
-
Select the system you want to use from the Source Control System drop-down list.
Only source control systems that are defined in your registry (HKEY_LOCAL_MACHINE\SOFTWARE\SourceCodeControlProvider\InstalledSCCProviders) appear in the drop-down list.
-
Type in your user name for the source control system.
Some source control systems use a login name from your registry rather than the user name that you enter here. For these systems (such as Perforce or PVCS), you can leave this field blank.
-
Click the ellipsis button next to the Project text box.
A dialog box from your source control system displays. Typically it allows you to select or create a source control project.
The dialog box displayed for PBNative is shown below:
-
Fill in the information required by your source control system and click OK.
The Project field on the Source Control page of the Workspace Properties dialog box is typically populated with the project name from the source control system you selected. However, some source control systems (such as Perforce or Vertical Sky) do not return a project name. For these systems, you can leave this field blank.
-
Type or select a path for the local root directory.
All the files that you check into and out of source control must reside in this path or in a subdirectory of this path.
-
(Option) Select the options you want for your local workspace connection to the source control server.
-
(Option) Click the Advanced button and make any changes you want to have apply to advanced options defined for your source control system.
The Advanced button might be grayed if you are not first connected to a source control server. If Advanced options are not supported for your source control system, you see only a splash screen for the system you selected and an OK button that you can click to return to the Workspace Properties dialog box.
-
Click Apply or click OK.
After a PowerBuilder workspace is assigned to an external SCC-compliant source control project through a connection profile, icons in the PowerBuilder System Tree display the source control status of all objects in the workspace. The same icons are also displayed for objects in the Library painter if the workspace to which they belong is the current workspace for PowerBuilder.
Source control icons
The icons and their meanings are described in the following tables.
|
Icon |
SCC-compliant source control status of object displaying icon |
|---|---|
|
|
The object resides only locally and is not under source control. |
|
|
The object is under source control and is not checked out by anyone. The object on the local computer is in sync with the object on the server unless the icon for indeterminate status also appears next to the same object. |
|
|
The object is checked out by the current user. |
|
|
The object is checked out by another user. |
|
|
The current status of an object under source control has not been determined. You are likely to see this icon only if the Perform Diff On Status Update check box is not selected and if diffs are not performed for your source control system based on version number. This icon can appear only in conjunction with the icon for a registered object (green dot icon) or for an object checked out by another user (red x icon). |
|
|
The object on the local computer is registered to source control, but is out of sync with the object on the server. This icon can also appear with the icon for an object checked out by another user. The Perform Diff On Status Update check box must be selected for this icon to display. |
Compound icons with a red check mark can display only if your SCC provider permits multiple user checkouts. These icons are described in the following table:
|
Icon |
Source control status of object displaying icon |
|---|---|
|
|
The object is under source control and is checked out nonexclusively by another user. PowerBuilder allows a concurrent checkout by the current user. |
|
|
The object is checked out by both the current user and another user. |
|
|
The object is checked out nonexclusively by another user and the version in the current user's local path is out of sync. |
For more information on allowing multiple user checkouts, see Checking objects out from source control.
Pop-up menus
Pop-up menus for each object in the workspace change dynamically to reflect the source control status of the object. For example, if the object is included in a source-controlled workspace but has not been registered to source control, the Add To Source Control menu item is visible and enabled in the object's pop-up menu. However, other source control menu items such as Check In and Show Differences are not visible until the object is added to source control.
Library painter Entry menu
Additional status functionality is available from the Entry menu of the Library painter. Depending on the source control system you are using, you can see the owner of an object and the name of the user who has the object checked out. For most source control systems, you can see the list of revisions, including any branch revisions, as well as version labels for each revision.
Library painter selections
When a painter is open, menu commands apply to the current object or objects in the painter, not the current object in the System Tree. This can get confusing with the Library painter in particular, since Library painter views list objects only (much like the System Tree), and do not provide a more detailed visual interface for viewing current selections, as other painters do.
To view the status of source-controlled objects
-
In a Library painter view, select the object (or objects) whose status you want to determine.
-
Select Entry>Source Control>Source Control Manager Properties.
A dialog box from your source control system displays. Typically it indicates if the selected file is checked in, or the name of the user who has the file checked out. It should also display the version number of the selected object.
Displaying the version number in the Library painter
You can display the version number of all files registered in source control directly in the Library painter. You add a Version Number column to the Library painter List view by making sure the SCC Version Number option is selected in the Options dialog box for the Library painter.
For more information, see Controlling columns that display in the List view.
Viewing status information offline
You can work offline and still see status information from the last time you were connected to source control. However, you cannot perform any source control operations while you are offline, and you cannot save changes to source-controlled objects that you did not check out from source control before you went offline.
To be able to work offline, you should select the option on the Source Control page of the Workspace Properties dialog box that indicates you sometimes work offline. If you select this option, a dialog box displays each time you open the workspace. The dialog box prompts you to select whether you want to work online or offline.
For more information about setting source control options for your workspace, see Setting up a connection profile.
About the PBC file
If you opt to work offline, PowerBuilder looks for (and imports) a PBC file in the local root directory. The PBC file is a text file that contains status information from the last time a workspace was connected to source control. PowerBuilder creates a PBC file only from a workspace that is connected to source control. Status information is added to the PBC file from expanded object nodes (in the System Tree or in a Library painter view) at the time you exit the workspace.
If a PBC file already exists for a workspace that is connected to source control, PowerBuilder merges status information from the current workspace session to status information already contained in the PBC file. Newer status information for an object replaces older status information for the same object, but older status information is not overwritten for objects in nodes that were not expanded during a subsequent workspace session.
Backing up the PBC file
You can back up the PBC file with current checkout and version information by selecting the Backup SCC Status Cache menu item from the Library painter Entry>Source Control menu, or from the pop-up menu on the current workspace item in the System Tree. The Library painter menu item is only enabled when the current workspace file is selected.
The Backup SCC Status Cache operation copies the entire contents of the refresh status cache to the PBC file in the local project path whether the status cache is dirty or valid. To assure a valid status cache, you can perform a Refresh Status operation on the entire workspace before backing up the SCC status cache.
For information about refreshing the status cache, see Refreshing the status of objects.
PowerBuilder uses an array of object file names that it passes to a source control system in each of its SCC API requests. The SCC specification does not mention an upper limit to the number of files that can be passed in each request, but the default implementation in PowerBuilder limits SCC server requests to batches of 25 objects.
A PB.INI file setting allows you to override the 25-file limit on file names sent to the source control server in a batched request. You can make this change in the Library section of the PB.INI file by adding the following instruction:
SccMaxArraySize=nn
where nn is the number of files you want PowerBuilder to include in its SCC API batch calls. Like other settings in the PB.INI file, the SccMaxArraySize parameter is not case sensitive.
When you connect to a source control system, PowerBuilder instantiates a Java VM by default. For certain SCC programs, such as Borland's StarTeam or Serena's TrackerLink, the Java VM instantiated by PowerBuilder conflicts with the Java VM instantiated by the SCC program. To prevent Java VM conflicts, you must add the following section and parameter setting to the PB.INI file:
[JavaVM] CreateJavaVM=0
By adding this section and parameter setting to the PB.INI file, you prevent PowerBuilder from instantiating a Java VM when it connects to a source control system.
The following schema shows a directory structure for files in the local PowerBuilder workspace and on the source control server. File types in the local root path that can be copied to the source control server from PowerBuilder are displayed in bold print. File types displayed in normal print are not copied. Asterisks shown before a file extension indicate variable names for files of the type indicated by the extension. The asterisk included in a file extension is also a variable. The variable for the extension depends on the type of object exported from a PBL, so it would be "w" for a window, "u" for a user object, and so on.
Typically, the source control server files are stored in a database but preserve the file system structure. Files in any deployment configuration directories can be regenerated automatically by building and deploying the files in the Source directory.
Temporary files in local root path
When you add or check in a PowerScript object to source control, PowerBuilder first exports the object as a temporary file (*.SR*) to your local target directory. For some source control systems, you might choose to delete temporary files from the local root path.
- Adding objects to source control
- Checking objects out from source control
- Checking objects in to source control
- Clearing the checked-out status of objects
- Synchronizing objects with the source control server
- Refreshing the status of objects
- Comparing local objects with source control versions
- Displaying the source control version history
- Removing objects from source control
The following source control operations are described in this section:
Source control operations on workspace and PBL files are performed on the objects contained in the current workspace or in target PBLs, not on the actual PBW and PBL files. The PBW and PBL files cannot be added to source control through the PowerBuilder interface. Source control operations are not enabled for target PBD files or for any of the objects in target PBD files.
You add an object to your source control project by selecting the Add To Source Control menu item from the object's pop-up menu in the System Tree or in the Library painter. You can also select an object in a Library painter view and then select Entry>Source Control>Add To Source Control from the Library painter menu bar.
What happens when you add objects to source control
When you add an object to source control, the icon in front of the object changes from a plus sign to a green dot, indicating that the object on the local computer is in sync with the object on the server.
PowerBuilder creates read-only object files in the local root directory for each PowerBuilder object that you add to source control. These files can be automatically deleted if you selected the Delete PowerBuilder Generated Object Files option as a source control connection property (although you cannot do this for certain SCC systems such as Perforce or ClearCase).
Read-only attributes are not changed by PowerBuilder if you later remove a workspace containing these files from source control.
Adding multiple objects to source control
If the object you select is a PowerBuilder workspace, a dialog box displays listing all the objects for that workspace that are not currently under source control (although the workspace PBW and target PBLs are not included in the list). If the object you select is a PowerBuilder target, and at least one of the objects in that target has not been registered with the current source control project, PowerBuilder displays a dialog box that prompts you to:
-
Select multiple files contained in the target
-
Register the target file only
If you select the multiple files radio button, another dialog box displays with a list of objects to add to source control. A check box next to each object lets you select which objects you want to add to source control. By default, check boxes are selected for all objects that are not in your source control project. They are not selected for any object already under source control.
You can resize all source control dialog boxes listing multiple files by placing a cursor over the edge of a dialog box until a two-headed arrow displays, then dragging the edge in the direction of one of the arrow heads.
Selecting multiple files from a PBL
If you select Add To Source Control for a target PBL, you immediately see the list of multiple files from that PBL in the Add To Source Control dialog box. There is no need for an intervening dialog box as there is for a target or workspace, since you cannot register a PBL file to source control from the PowerBuilder UI -- you can only register the objects contained in that PBL.
You can also select multiple objects to add to source control from the List view of the Library painter (without selecting a workspace, target, or PBL).
The Add To Source Control menu item is disabled for all objects that are registered in source control except workspaces and targets. If you select the Add To Source Control menu item for a workspace or target in which all the objects are already registered to source control, PowerBuilder displays the Add To Source Control dialog box with an empty list of files. You cannot add objects to your source control project that are already registered with that project.
Creating a mapping file for target PBLs
When you add a target or an object (in a target that is not under source control) to source control, PowerBuilder creates a PBG file. A PBG file maps objects in a target to a particular PBL in a PowerScript or .NET target. One PBG file is created per PBL, so there can be multiple PBG files for these types of target.
If a PBG file already exists for a target PBL containing the object you are adding to source control, PowerBuilder checks the PBG file out of source control and adds the name of the object to the names of objects already listed in the PBG file. It then checks the PBG file back into source control.
The PBG files are used by PowerBuilder to make sure that objects are distributed to the correct PBLs and targets when you check the objects out (or get the latest versions of the objects) from source control.
If your source control system requires comments on registration and check-in, you get separate message boxes for the PBG file and the objects that you are adding to source control. If your source control system gives you the option of adding the same comments to all the objects you are registering, you can still get additional message boxes for PBG files, since PBG files are checked in separately.
Because it is possible for PBG files to get out of sync, it is important that the project manager monitor these files to make sure they map all objects to the correct PBLs and contain references to all objects in the source control project. However, you cannot explicitly check in or check out PBG files through the PowerBuilder SCC API.
For more information on modifying PBG files, see Editing the PBG file for a source-controlled target.
What happens on checking out an object
When you check out an object, PowerBuilder:
-
Locks the object in the archive so that no one else can modify it -- unless your source control system permits multiple user checkouts
-
Copies the object to the directory for the target to which it belongs
-
For a PowerScript object, compiles the object and regenerates it in the target PBL to which it is mapped
-
Displays a check mark icon next to the object in your System Tree and in your Library painter to show that the object has been checked out
Checking out multiple objects
If you select the Check Out menu item for a PowerBuilder target that is not already checked out, and at least one of the objects in that target is available for checkout, PowerBuilder displays a dialog box that prompts you to:
-
Select multiple files contained in the target
-
Check out the target file only
If you select the multiple file option, or if the target file is already checked out, the Check Out dialog box displays the list of objects from that target that are available for checkout. A check box next to each object in the list lets you choose which objects you want to check out. By default, check boxes are selected for all objects that are not currently checked out of source control.
The Deselect All button in the Check Out dialog box lets you clear all the check boxes with a single click. When none of the objects in the list is selected, the button text becomes Select All, and you can click the button to select all the objects in the list.
You can also select multiple objects (without selecting a target) in the List view of the Library painter. The PowerBuilder SCC API does not let you check out an object that you or someone else has already checked out or that is not yet registered with source control. If you use multiple object selection to select an object that is already checked out, PowerBuilder does not include this object in the list view of the Check Out dialog box.
Multiple user checkout. Checking out an object from a source control system usually prevents other users from checking in modified versions of the same object. Some source control systems, such as Serena Version Manager (formerly Merant PVCS) and MKS Source Integrity, permit multiple user checkouts. In these systems, you can allow shared checkouts of the same object.
By default, PowerBuilder recognizes shared checkouts from SCC providers that support multiple user checkouts. PowerBuilder shows a red check mark as part of a compound icon to indicate that an object is checked out to another user in a shared (nonexclusive) mode. You can check out an object in shared mode even though another user has already checked the object out.
Managing multiple user check-ins
If you allow multiple user checkouts, the SCC administrator should publish a procedure that describes how to merge changes to the same object by multiple users. Merge functionality is not automatically supported by the SCC API, so checking in an object in shared mode might require advanced check-in features of the source control system. Merging changes might also require using the source control administration utility instead of the PowerBuilder user interface.
If your SCC provider permits multiple user checkouts, you can still ensure that an item checked out by a user is exclusively reserved for that user until the object is checked back in, but only if you add the following instruction to the Library section of the PB.INI file:
[Library] SccMultiCheckout=0
After you add this PB.INI setting, or if your SCC provider does not support multiple user checkouts, you will not see the compound icons with red check marks, and all items will be checked out exclusively to a single user. For source control systems that support multiple user checkouts, you can re-enable shared checkouts by setting the SccMultiCheckout value to 1 or -1.
Creating a source control branch
If your source control system supports branching and its SCC API lets you check out a version of an object that is not the most recent version in source control, you can select the version you want in the Advanced Check Out dialog box (that you access by clicking the Advanced button in the Check Out dialog box). When you select an earlier version, PowerBuilder displays a message box telling you it will create a branch when you check the object back in. You can click Yes to continue checking out the object or No to leave the object unlocked in the source control project. If this is part of a multiple object checkout, you can select Yes To All or No To All.
If you want just a read-only copy of the latest version of an object
Instead of checking out an object and locking it in the source control system, you can choose to get the latest version of the object with a read-only attribute. See Synchronizing objects with the source control server.
To check out an object from source control:
-
Right-click the object in the System Tree or in a Library painter view and select Check Out from the pop-up menu
or
Select the object in a Library painter view and select Entry>Source Control>Check Out from the Library painter menu.
The Check Out dialog box displays the name of the object you selected. For PowerScript objects, the object listing includes the name of the PBL that contains the selected object.
If you selected multiple objects, the Check Out dialog box displays the list of objects available for checkout. You can also display a list of available objects when you select a target file for checkout. A check mark next to an object in the list marks the object as assigned for checkout.
-
Make sure that the check box is selected next to the object you want to check out, and click OK.
When you finish working with an object that you checked out, you must check it back in so other developers can use it, or you must clear the object's checked-out status.You cannot check in objects that you have not checked out.
If you do not want to use the checked-out version
Instead of checking an entry back in, you can choose not to use the checked-out version by clearing the checked-out status of the entry. See Clearing the checked-out status of objects.
Checking in multiple objects
If you select the Check In menu item for a workspace, PowerBuilder lists all the objects in the workspace that are available for check-in. If you select the Check In menu item for a PowerBuilder target that is currently checked out to you, and at least one of the objects in that target is also checked out to you, PowerBuilder displays a dialog box that prompts you to:
-
Select multiple files contained in the target
-
Check in the target file only
If you select the multiple file option, or if the target file is not currently checked out to you, the Check In dialog box displays the list of objects from that target that are available for you to check in. A check box next to each object in the list lets you choose which objects you want to check in. By default, check boxes are selected for all objects that you currently have checked out of source control.
The Deselect All button in the Check In dialog box lets you clear all the check boxes with a single click. When none of the objects in the list is selected, the button text becomes Select All, and you can click the button to select all the objects in the list.
You can also select multiple objects (without selecting a workspace or target) in the List view of the Library painter. The PowerBuilder SCC API does not let you check in an object that you have not checked out of source control. If you use multiple object selection to select an object that is not checked out to you, PowerBuilder does not include this object in the list view of the Check In dialog box.
To check in objects to source control
-
Right-click the object in the System Tree or in a Library painter view and select Check In from the pop-up menu
or
Select the object in a Library painter view and select Entry>Source Control>Check In from the Library painter menu.
The Check In dialog box displays the name of the object you selected. If you selected multiple objects or a workspace, the Check In dialog box displays the list of objects available for check-in. You can also display a list of available objects when you select a target file. A check mark next to an object in the list marks the object as assigned for check-in.
-
Make sure the check box is selected next to the object you want to check in and click OK.
Sometimes you need to clear (revert) the checked-out status of an object without checking it back into source control. This is usually the case if you modify the object but then decide not to use the changes you have made. When you undo a checkout on an object, PowerBuilder replaces your local copy with the latest version of the object on the source control server. For PowerScript and .NET targets, it compiles and regenerates the object in its target PBL.
Clearing the status of multiple objects
If you select the Undo Check Out menu item for a PowerBuilder target that is checked out to you, and at least one of the objects in that target is also checked out to you, PowerBuilder displays a dialog box that prompts you to:
-
Select multiple files contained in the target
-
Undo the checked-out status for the target file only
If you select the multiple file option, or if the target file is not currently checked out to you, the Undo Check Out dialog box displays the list of objects from that target that are locked by you in source control. A check box next to each object in the list lets you choose the objects for which you want to undo the checked-out status. By default, check boxes are selected for all objects that are currently checked out to you from source control.
You can also select multiple objects (without selecting a target) in the List view of the Library painter. The PowerBuilder SCC API does not let you undo the checked-out status of an object that you have not checked out of source control. If you use multiple object selection to select an object that is not checked out to you, PowerBuilder does not include this object in the list view of the Undo Check Out dialog box.
To clear the checked-out status of entries
-
Right-click the object in the System Tree or in a Library painter view and select Undo Check Out from the pop-up menu
or
Select the object in a Library painter view and select Entry>Source Control>Undo Check Out from the Library painter menu.
The Undo Check Out dialog box displays the name of the object you selected. If you selected multiple objects, the Undo Check Out dialog box displays the list of objects in the selection that are currently checked out to you. You can also display a list of objects that are checked out to you when you select a target file.
-
Make sure that the check box is selected next to the object whose checked-out status you want to clear, and click OK.
You can synchronize local copies of PowerBuilder objects with the latest versions of these objects in source control without checking them out from the source control system. The objects copied to your local computer are read-only. The newly copied PowerScript objects are then compiled into their target PBLs.
If there are exported PowerScript files in your local path that are marked read-only, and you did not select the Suppress Prompts To Overwrite Read-Only Files option, your source control system might prompt you before attempting to overwrite these files during synchronization. If you are synchronizing multiple objects at the same time, you can select:
-
Yes To All, to overwrite all files in your selection
-
No To All, to cancel the synchronization for all objects in the selection that have writable files in the local path
Synchronizing an object does not lock that object on the source control server. After you synchronize local objects to the latest version of these objects in source control, other developers can continue to perform source control operations on these objects.
If you want only to check whether the status of the objects has changed on the source control server, you can use the Refresh Status menu item from the Library painter Entry menu or System Tree pop-up menus. The Refresh Status command runs on a background thread. If you do not use the Refresh Status feature before getting the latest versions of workspace or target objects, then PowerBuilder has to obtain status and out-of-sync information from the SCC provider in real time during a GetLatestVersion call.
For more information, see Refreshing the status of objects.
To synchronize a local object with the latest source control version
-
Right-click the object in the System Tree or in a Library painter view and select Get Latest Version from the pop-up menu
or
Select the object in a Library painter view and select Entry>Source Control>Get Latest Version from the Library painter menu.
The Get Latest Version dialog box displays the name of the object you selected. If you selected multiple objects in the Library painter List view, the Get Latest Version dialog box lists all the objects in your selection. If you selected a workspace, the Get Latest Version dialog box lists all the objects referenced in the PBG files belonging to your workspace. You can also display a list of available objects (from the PBG files for a target) when you select the Get Latest Version menu item for a target file.
A check mark next to an object in the list assigns the object for synchronization. By default only objects that are currently out of sync are selected in this list. You can use the Select All button to select all the objects for synchronization. If all objects are selected, the button text becomes Deselect All. Its function also changes, allowing you to clear all the selections with a single click.
-
Make sure that the check box is selected next to the object for which you want to get the latest version, and click OK.
PowerBuilder uses the source control connection defined for a workspace to check periodically on the status of all objects in the workspace. You can set the status refresh rate for a workspace on the Source Control page of the Workspace Properties dialog box. You can also select the Perform Diff on Status Update option to detect any differences between objects in your local directories and objects on the source control server.
For more information about source control options you can set on your workspace, see Setting up a connection profile.
PowerBuilder stores status information in memory, but it does not automatically update the source control status of an object until a System Tree or Library painter node containing that object has been expanded and the time since the last status update for that object exceeds the status refresh rate.
Status information can still get out of sync if multiple users access the same source control project simultaneously and you do not refresh the view of your System Tree or Library painter. By using the Refresh Status menu item, you can force a status update for objects in your workspace without waiting for the refresh rate to expire, and without having to open and close tree view nodes containing these objects.
The Refresh Status feature runs in the background on a secondary thread. This allows you to continue working in PowerBuilder while the operation proceeds. When the Refresh Status command is executed, your SCC status cache is populated with fresh status values. This allows subsequent operations like a target-wide synchronization (through a GetLatestVersion call) to run much faster.
To refresh the status of objects
-
Right-click the object in the System Tree or in a Library painter view and select Refresh Status from the pop-up menu
or
Select the object in a Library painter view and select Entry>Source Control>Refresh Status from the Library painter menu.
If the object you selected is not a workspace, target, or PBL file, the object status is refreshed and any change is made visible by a change in the source control icon next to the object. If you selected an object in a Library painter view, the status of this object in the System Tree is also updated.
For information about the meaning of source control icons in PowerBuilder, see Viewing the status of source-controlled objects.
-
If the object you selected in step 1 is a workspace or target file, select a radio button to indicate whether you want to refresh the status of the selected file only or of multiple files in the workspace or target.
-
If the object you selected in step 1 is a PBL, or if you selected the multiple files option in step 2, make sure that the check box is selected next to the object or objects whose status you want to refresh, and click OK.
Status is refreshed for every object selected in the Refresh Status dialog box. Any change in status is made visible by a change in the source control icon next to the objects (in the selected workspace, target, or PBL) that are refreshed.
The PowerBuilder SCC API lets you compare an object in your local directory with a version of the object in the source control archive (or project). By default, the comparison is made with the latest version in the archive, although most source control systems let you compare your local object to any version in the archive. Using this feature, you can determine what changes have been made to an object since it was last checked into source control.
Setting up PBNative for object comparisons
PBNative does not have its own visual difference utility, but it does allow you to select one that you have already installed. You must use only a 32-bit visual difference utility for the object comparisons. You can select any or all of the following options when you set up the utility to work with a PBNative repository:
|
Option |
Select this if |
|---|---|
|
Enclose file names in double quotes |
Your visual difference utility does not handle spaces in file names. |
|
Refer to local PBL entry as argument #1 |
You do not want the visual difference utility to use the repository object as the first file in a file comparison. |
|
Generate short (8.3) file names |
Your visual difference utility does not handle long file names. |
|
Generate an extra space prior to file arguments |
Your visual difference utility requires an extra space between files that are listed as arguments when you open the utility from a command line. This option was added for backward compatibility only, as an extra space was automatically added by PowerBuilder 8. |
To set up PBNative for object comparisons
-
Right-click the Workspace object in the System Tree and click the Source Control tab in the Workspace Properties dialog box.
PBNative should be your selection for the source control system, and you must have a project and local root directory configured. If you are connected already to source control, you can skip the next step.
-
Click Connect.
The Connect button is disabled if you are already connected to source control.
-
Click Advanced.
The PBNative Options dialog box displays.
-
Type the path to a visual difference utility followed by the argument string required by your utility to perform a diff (comparison) on two objects.
Typically, you would add two %s parameter markers to indicate where PowerBuilder should perform automatic file name substitution. The following figure shows a setting used to call the Microsoft WinDiff utility:
-
(Optional) Select any or all of the check box options in the PBNative Command Options dialog box for your object comparisons.
-
Click OK twice.
You are now set to use your visual difference utility to compare objects on the local computer and the server.
Using Show Differences to compare objects
You can select Show Differences from a pop-up menu or from the Library painter menu bar. If the object you want to compare has not been added to the source control project defined for your workspace, the Show Differences menu item is not available.
To compare a local object with the latest source control version
-
Right-click the object in the System Tree or in a Library painter view and select Show Differences from the pop-up menu
or
Select the object in a Library painter view and select Entry>Source Control>Show Differences from the Library painter menu bar.
A dialog box from your source control system displays.
PBNative connections
Skip the next step if you are using a visual difference utility with PBNative. The difference utility displays the files directly or indicates that there are no differences between the files.
-
Select the source control comparison options you want and click OK.
Some source control systems support additional comparison functions. You may need to run the source control manager for these functions. See your source control system documentation for more information.
For some source control systems, the PowerBuilder SCC API lets you show the version control history of an object in source control. Using this feature, you can determine what changes have been made to an object since it was first checked into source control.
The Show History menu item is not visible if the object for which you want to display a version history has not been added to the source control project defined for your workspace. It is grayed out if your source control system does not support this functionality through the PowerBuilder SCC API.
To display the source control version history
-
Right-click the object in the System Tree or in a Library painter view and select Show History from the pop-up menu
or
Select the object in a Library painter view and select Entry>Source Control>Show History from the Library painter menu bar.
A dialog box from your source control system displays.
-
Select the source control options you want and click OK.
Some source control systems support additional tracing and reporting functions for objects in their archives. You may need to run the source control manager for these functions. See your source control system documentation for more information.
The PowerBuilder SCC API lets you remove objects from source control, although for some source control systems, you may have to use the source control manager to delete the archives for the objects you remove. You cannot remove an object that is currently checked out from source control.
You cannot delete a source-controlled object from a local PowerBuilder workspace before that object has been removed from source control. There is no requirement, however, that the source control archive be deleted before you delete the object from its PowerBuilder workspace.
To remove objects from source control
-
Select the object in a Library painter view and select Entry>Source Control>Remove From Source Control from the Library painter menu.
The Remove From Source Control dialog box displays the name of the object you selected.
If you selected multiple objects or a workspace, the Remove From Source Control dialog box displays the list of objects in your selection that are not currently checked out from source control. You can also display a list of available objects when you select the Remove From Source Control menu item for a target file. A check mark next to an object in the list marks the object as assigned for removal from source control.
-
Make sure that the check box is selected next to the object you want to remove, and click OK.
Settings for managing source control operations
In addition to the SccMaxArraySize described in Fine-tuning performance for batched source control requests, and SccMultiCheckout described in Multiple user checkout, there are other PB.INI parameters you can add that affect source control operations.
|
PB.INI parameter |
Permitted values |
Description |
|---|---|---|
|
SccCOImport |
full inc outofdate full outofdate inc outofdate |
During checkout the default behavior is to import and compile only the objects being checked out. You can make the compile more inclusive by adding this parameter to the initialization file and assigning either the "full" or "inc" value to it. You can use the "outofdate" value to avoid unnecessary import and compile operations. For a fuller description of the permitted values, see the following table. |
|
SccUCImport |
full inc outofdate full outofdate inc outofdate |
When you revert a checkout, the default behavior is to refresh and compile only those objects in the local project path that were originally checked out. You can make the compile more inclusive by adding this parameter and assigning either the "full" or "inc" value to it. You can use the "outofdate" value to avoid unnecessary import and compile operations. For the meaning of the permitted values, see the following table. |
|
SccGLImport |
full inc |
When you issue a GetLatestVersion call, the default behavior is to refresh and compile only the objects in the request. You can make the compile more inclusive by adding this parameter and assigning a permitted value to it. For the meaning of the permitted values, see the following table. |
|
SccRBImport |
full inc |
When you issue a checkout, get latest version, or undo checkout call, images of the requested objects are exported to a temporary directory. When refreshed objects fail to compile, a dialog box asks whether you want to continue with or cancel the operation for all objects that fail to compile. If you select Cancel, the older images for the objects that fail to compile are reimported from the temporary directory to the local project path. Whenever object images are rolled back in this manner, you can force an incremental or full compilation of the entire target by adding the SccRBImport parameter and assigning a permitted value to it. For the meaning of the permitted values, see the following table. |
|
SccMaxArraySize |
nn (positive integer) |
Allows you to override the 25-file limit on file names sent to the source control server in a batched request. For more information, see Fine-tuning performance for batched source control requests. |
|
SccCaseSensitive |
0 or 1 (1 is default for Telelogic Synergy, 0 for all other SCC providers) |
By default, PowerBuilder uses a case sensitivity setting that is compatible with the SCC provider you are using. You can override the default setting by adding this parameter and assigning a different value. A value of 1 means that object names checked into source control are case sensitive, and a value of 0 means that they are not case sensitive. |
|
SccMultiCheckout |
0 or 1 (1 is default for SCC providers that support multiuser checkouts, 0 for providers that do not support multiuser checkout) |
If your SCC provider permits multiple user checkouts, you can use this initialization parameter to ensure that an item checked out by a user is exclusively reserved for that user until the object is checked back in. For more information, see Multiple user checkout. |
|
SccCheckoutNoLock |
0 or 1 (1 is default for MKS Source Integrity, 0 for all other providers |
Based on known defaults for the SCC provider you are using, PowerBuilder determines whether locks are added in source control to objects that you check out. You can override the default setting for some SCC providers by adding this parameter and assigning a different value. If the SCC provider permits checkouts of objects without locking them, a value of 1 means that no locks are added for objects that you check out. A value of 0 makes sure that locks are added for these objects. |
Permitted values for Import parameters
The following table describes the effect of permitted values for the SccCOImport, SccUCImport, SccGLImport, and SccRBImport parameters in the PB.INI initialization file. You can also add an import parameter without assigning it a value. This has the same effect as the default behavior during checkout, undo checkout, get latest version, and rollback operations.
|
Permitted value |
Description |
|---|---|
|
full |
Forces a full build of the target after the requested source control operation is completed. For SccCOImport and SccUCImport, you can combine the "full" value with the "outofdate" value to reduce the number of objects imported from the local project path to the target PBLs before a full rebuild. You combine the values by separating them with a single space, as shown in the following example: SccUCImport= full outofdate. For SccRBImport, if rollback fails for any reason, the build operation is not performed. |
|
inc |
Examines the entire target for additional objects that are descendants of objects or have dependencies on the objects that are included in the initial source control request. The dependent objects are compiled and regenerated as part of an incremental build, along with the objects in the initial request. For SccCOImport and SccUCImport, you can combine the "inc" value with the "outofdate" value to reduce the number of objects imported from the local project path to the target PBLs before an incremental rebuild. You combine the values by separating them with a single space, as shown in the following example: SccUCImport= inc outofdate. For SccRBImport, if rollback fails for any reason, the build operation is not performed. |
|
outofdate |
Compares the exported object images to the source code in target PBLs after an initial checkout or undo checkout operation. If the code in the PBLs is identical to the object images, the object images are not imported. The source code for identical PBL objects is also not compiled unless you also assign "full" or "inc" to the SccCOImport or SccUCImport parameters. The "outofdate" value is not available for the SccGLImport and SccRBImport parameters. Typically GetLatestVersion calls are made for objects that are assumed to be out of sync, in which case the out-of-date comparison is not expected to be useful. Also, object images that have been rolled back should always be reimported and compiled to assure the integrity of the target PBLs. |
Settings for troubleshooting problems with source control
In addition to the initialization parameters that can help with managing source control operations, there are also parameters you can use to troubleshoot problems with source control. These parameters should not be used in normal operations. They should be used only for diagnosing a problem with source control. The following table describes these parameters.
|
PB.INI parameter |
Permitted values |
Description |
|---|---|---|
|
SccExtensions |
0 or 1 (1 is default) |
Add this parameter and set it to 0 to disable SccQueryInfoEx calls when your source control provider supports this extension to the SCC API. You should do this either to Measure performance differences between SccDiff and SccQueryInfoEx calls. Test for incompatibilities between PowerBuilder clients and SCC provider DLL implementations. For more information about SccQueryInfoEx calls, see Extension to the SCC API. |
|
SccLogLevel |
1 or 3 (1 is default) |
Add this parameter and set it to 3 to enable more detailed tracing of SCC requests and the responses from the SCC provider. Increased tracing detail requires more file input and output, so this setting should be used only for diagnosing problems. |
|
SccMultithread |
0 or 1 (1 is default) |
Add this parameter and set it to 0 to disable multithreading. Disabling multithreading can cause significant delays when first connecting to source control or when expanding a node in the PowerBuilder System Tree, so this setting should be used only to diagnose integration issues with a specific provider or to work around a known defect. |
|
SccDiffStrategy |
nn (positive integer) |
Depending on the capabilities of an SCC provider, different strategies are used for determining whether a PBL object is out of sync with object files in the SCC repository. By default, a comparison is made by version number if the SCCQueryInfoEx API extension is supported and the SccExtensions parameter is not set to 0. Otherwise, a provider-specific backup strategy is used for the object comparisons. You can override the default comparison strategy by adding the SccDiffStrategy parameter to the initialization file and assigning an appropriate value to it. For more information, see Comparison strategies. |
By default, PowerBuilder uses the SCCQueryInfoEx API extension command to compare objects in target PBLs with object files in a source control repository.
For more information on the SCCQueryInfoEx API extension command, see Extension to the SCC API.
A backup strategy is set for SCC providers that do not support the API extension. The default backup strategy for all SCC providers except ClearCase and Perforce is to issue an SccDiff command. For ClearCase, the backup strategy compares the PBL object with the local project path object file. For Perforce versions earlier than 2008, the strategy for comparing differences first examines the SCC_STATUS_OUTOFDATE bit returned by the SccQueryInfo command and then compares the PBL object with the local project page object file.
You can override the default comparison strategy by adding the SccDiffStrategy parameter to the initialization file and assigning a value to it from the following table. You can also add the values together to use multiple comparison strategies, as long as those strategies are supported by your SCC provider.
Perforce 2008 and later
The Perforce client behavior changed with the 2008 version. SccQueryInfo does not return information about added objects to a Perforce 2008 depot. Therefore, for this SCC client, it is best to perform full synchronizations from the Perforce management utility or by using the OrcaScript scc refresh target <full> command. You also need to add the SccDiffStrategy parameter to the initialization file and set its bit value to 08 to make sure that the source code in the target PBLs match the object files in the local project path.
|
Parameter value |
Object comparison strategy |
|---|---|
|
02 (default) |
Compares by version number (SCCQueryInfoEx) -- not supported by all vendors |
|
04 |
Examines the SCC_STATUS_OUTOFDATE bit from the SccQueryInfo command to determine which objects are out of sync |
|
08 |
Compares the source code in the target PBLs with object files in the local project path |
|
16 |
Uses the SccDiff command in quiet mode |
Objects in targets under source control must be managed differently than the same objects in targets that are not under source control.
You must check out a target file from source control before you can modify its properties. If objects in a source-controlled target are not themselves registered in source control, you can add them to or delete them from the local target without checking out the target. However, you must remove a source-controlled object from the source control system before you can delete the same object from the local copy of the target (whether or not the target itself is under source control).
Although you can add objects to a source-controlled target without checking out the target from source control, you cannot add existing libraries to the library list of a source-controlled target unless the target is checked out.
For information on removing an object from source control, see Removing objects from source control.
Although you can open objects in a PowerBuilder painter when they are checked in to source control, until you check them out again, any changes you make to those objects cannot be saved. By default, when you try to open an object under source control, PowerBuilder provides a warning message to let you know when the object is not checked out. You can avoid this type of warning message by clearing the "Suppress prompts to overwrite read-only files" check box on the Source Control tab of the Workspace Properties dialog box.
If you did not change the default, you can still select a check box on the first warning message that displays. After you select the "Do not display this message again" check box in a warning message box and click Yes, the check box on the Source Control tab is automatically cleared. This prevents warning messages from displaying the next time you open objects that are checked in to source control. Although warning messages do not display, you still cannot save any changes you make to these objects in a PowerBuilder painter.
You cannot copy a source-controlled object to a destination PBL in the same directory as the source PBL. Generally when you work with source control, objects with the same name should not exist in more than one PBL in the same directory.
Moving an object that is not under source control to a destination PBL having a source-controlled object with the same name is permitted only when the second object is checked out of source control.
You cannot move an object from a source PBL if the object is under source control, even when the object has been checked out. The right way to move an object under source control is described below.
PowerBuilder creates and uses PBG files to determine if any objects present on a source control server are missing from local PowerScript or .NET targets. Up-to-date PBG files insure that the latest objects in source control are available to all developers on a project, and that the objects are associated with a named PBL file.
Ideally, PBG files are not necessary. If the source control system exposes the latest additions of objects in a project through its SCC interface, PowerBuilder can obtain the list of all objects added to a project since the last status refresh. However, many source control systems do not support this, so PowerBuilder uses the PBG files to make sure it has an up-to-date list of objects under source control.
PBG files are registered and checked in to source control separately from all other objects in PowerBuilder. They are automatically updated to include new objects that are added to source control, but they can easily get out of sync when multiple users simultaneously register objects to (or delete objects from) the same source control project. For example, it is possible to add an object to source control successfully yet have the check-in of the PBG file fail because it is locked by another user.
You cannot see the PBG files in the System Tree or Library painter unless you set the root for these views to the file system. To edit PBG files manually, you should check them out of source control using the source control manager and open them in a text editor. (If you are using PBNative, you can edit PBG files directly in the server storage location, without checking them out of source control.)
You can manually add objects to the PBG file for a PowerBuilder library by including a new line for each object after the @begin Objects line. The following is an example of the contents of a PBG file for a PBL that is saved to a subdirectory (target1) of the workspace associated with the source control project:
Upgrading from earlier versions of PowerBuilder
There are different strategies for upgrading existing source control projects from earlier versions of PowerBuilder. To upgrade a target from PowerBuilder 8 or later, you can check the target out from source control, then add the target to a workspace in the new version of PowerBuilder. When the Migrate Application dialog box prompts you to migrate the libraries in the application library list, click OK to begin the migration.
If you change the directory hierarchy for target libraries in the new version of PowerBuilder, you should use the Existing Application target wizard to create a new target instead of adding and upgrading a PowerBuilder 8 or later target. If you keep the old target file (PBT) in the new target path, you must give the new target a different name or the wizard will not be able to create a new PBT.
For information on using the Existing Application target wizard, see Using the Existing Application target wizard.
When you open a PowerBuilder 8 or later workspace in the current version of PowerBuilder, a dialog box prompts you to upgrade the workspace targets. If you select the No Prompting check box and click OK, the target libraries are upgraded without additional prompting, and the Migrate Application dialog box never displays. You can then add the migrated target objects to source control from the new version of PowerBuilder.
For more information about upgrade, see Upgrading targets.
Removing PowerBuilder 8
If you remove PowerBuilder 8 from a computer where you have already installed a later version of PowerBuilder, the setup program deletes the PBNative registry entry. Subsequently, if you want to use PBNative source control with PowerBuilder, you must reregister PBNAT.dll. Attempting to use PBNative before reregistering the DLL produces an error message that points out the problem and the solution. You can reregister the DLL by opening a DOS command box, changing to the %AppeonInstallPath%\PowerBuilder [version]\IDE directory, and entering the command REGSVR32 PBNAT.dll.
Removing PowerBuilder 9 or later does not remove the DLL or the registry entry for PBNative source control.
Upgrading from PowerBuilder 7 or earlier
Upgrading an application from PowerBuilder 7 or earlier requires a different approach, since workspaces and targets were introduced with PowerBuilder 8. You need to create a new workspace and appropriate targets for any PowerBuilder 7 (or older) objects that you are upgrading.
The strategies available to you or the project manager are:
To use the first strategy, you must keep a copy of the old version of PowerBuilder -- at least until you have finished upgrading all your source-controlled PBLs.
Source control in early PowerBuilder versions
Because workspaces and targets were not available in PowerBuilder prior to version 8, you must use the Existing Application wizard to create targets for applications that you built with PowerBuilder 7 or earlier PowerBuilder versions. A source control project in PowerBuilder 7 (or earlier PowerBuilder versions) was associated with a single application.
Beginning with PowerBuilder 8, source control is associated with a workspace that can have multiple targets and applications.
If you keep a copy of your old version of PowerBuilder, you can check out your application object and all other objects from source control to a work PBL. By checking out the objects in the older version of PowerBuilder, you make sure that no one else makes changes to the objects before you upgrade them to the current version of PowerBuilder.
Deciding on a directory hierarchy
You should decide on a directory hierarchy before you upgrade. PowerBuilder 7 and earlier versions required you to keep all source-controlled files in a single directory. Beginning with PowerBuilder 8, you can create subdirectories to contain each PBL in your library list. Although this is not required, it is useful in that it keeps objects from different PBLs separated in source control subprojects.
You must also decide whether to add a new target to an existing PowerBuilder workspace or to a new workspace that you create specifically for the target. You can then use the Existing Application target wizard to create a new target from the local copies of your registered PBLs (making sure to select all the supporting PBLs for your application on the Set Library Search Path page of the wizard). When you run the wizard, PowerBuilder prompts you to upgrade the PBLs you select.
After you have run the wizard and upgraded all the source-controlled PBLs, you can define the source control connection profile for the workspace to point to the old source control project if you want to maintain it, or to a new source control project if you do not. You can then check in or add the upgraded objects to source control and delete the work PBL containing the older versions of the objects. You do not need a separate work PBL in PowerBuilder 9 or later.
To migrate a source control project using the Existing Application wizard
-
From your old version of PowerBuilder, check out your objects to a work PBL.
-
Decide on a new file hierarchy for the libraries in your application library list.
You can keep all the libraries in the same directory if you want, but it can be advantageous to create separate subdirectories for each library in the list. If you plan to share libraries among different targets, you should structure the directories so that the common libraries are in the local root path of every target that uses them.
-
Create a new workspace in the new version of PowerBuilder, or open an existing workspace in the new version of PowerBuilder.
-
Create a new target using the Existing Application wizard.
-
In the wizard, point to the PBL with an Application object and add all the helper PBLs to the library search path.
PowerBuilder prompts you to upgrade the PBLs.
-
Click Yes to upgrade each library in the path.
-
Create a source connection profile for the workspace that points to the old source control project or to a new project.
-
Check in the upgraded objects to source control if you are using the old source control project, or add the upgraded objects to source control if you are using a new source control project.
-
Delete the work PBL whenever you want.
You can use your source control manager to check out all the old PowerBuilder objects to a named directory or folder. If you plan to use the same project to store your upgraded objects, you must make sure that the manager locks the files you check out of the source control archive.
You can create a new target using the Application target wizard in a new or existing workspace. The Application wizard lets you select or name a new PBL file to associate with the target it creates. You can use the Target property sheet to list any additional PBLs you want to associate with the target.
You can then import the files that you checked out of source control, distributing them as needed to the libraries you associated with the new target. After importing the files, you can upgrade the target by right-clicking it in the System Tree and selecting Migrate from the target pop-up menu. You should also do a full build of the target. After you have upgraded and built the target, you can define the connection profile for the workspace to point to the old source control project if you want to maintain it, or to a new source control project if you do not.
