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 |
|
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 Table 3-7. |
SccUCImport |
|
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 Table 3-7. |
SccGLImport |
|
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 Table 3-7. |
SccRBImport |
|
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 Table 3-7. |
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 |
|
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 |
|
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 |
|
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. |
Table 3-7 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: 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: 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. |
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. Table 3-8 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
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 Table 3-9. 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 |