Source code control is used for one or more reasons:
1. To provide for a single common location with a master set of the source code being developed.
2. To provide checkin/checkout capability to ensure that two developers do not attempt to make incompatible code changes at the same time
3. To provide a history of source code changes. This helps for instance by allowing changes that were done in error to be more easily reverted.
Prior to PowerBuilder 6, the source control options available from within PowerBuilder were limited. This was primarily because a custom driver had to be created that enabled PowerBuilder to talk to the target source control system. Everything changed with PowerBuilder 6, when PowerBuilder implemented a standard API based upon the Microsoft Source Code Control Interface (MSSCCI). In PowerBuilder 8, a PBNative option was added to provide an out-of-the-box source control option. However, PBNative provides “minimal” source code versioning capability.
Note that no matter what source control option you use, you should – at least within PowerBuilder Classic – use the source control menu options provided within the PowerBuilder IDE. That is because the PowerBuilder Classic IDE does not store individual source code files at the operating system level, but instead stores them in PowerBuilder libraries (PBLs). Attempting to add the PBLs to a source control system has significant limitations, including restricting checkin/checkout capability to a PBL (preventing other developers from working with any objects in the library that you aren’t working with) and dramatically limiting the ability to do version comparisons between edits. The PowerBuilder.Net IDE does store individual source code files at the operating system level, and as a result your source code control options are much more open and beyond the scope of this article.
Source code options for PowerBuilder Classic fall in three general categories:
1. Using PBNative: This is the out of the box solution. Note however that while it does provide for checkin/checkout capability to prevent more than one developer from editing the same source code at the same time, the approach provides little support for code versioning,
2. Using a source control system that supports MSSCCI. Once the client for such a system is installed on the workstation that PowerBuilder is installed on, the vendor should appear in the drop down within the PowerBuilder IDE for available source control systems. There are a number of such systems available. Two of interest because they are specifically designed for use with PowerBuilder are WizSource and PowerVSC. Historically (even prior to PowerBuilder 7) vendors such as PVCS and ClearCase were very popular. Other systems that support MSSCCI include Team Foundation Server, Plastic SCM, Surround SCM, and SourceAnywhere,
3. Use a non MSSCCI source control system for which there is a MSSCCI bridge product available. A number of newer source control systems that do not support MSSCCI have become very popular lately. Historically, CVS was a popular option, and more recently SVN, Git and Mercurial have become very popular. Such products can be used for source control from PowerBuilder provided there is an add-on utility that will convert the MSSCCI calls that the PowerBuilder IDE makes into the calls that the target source control system does understand. Some available ‘bridge’ products include:
CVS: TamTam CVS,
Mercurial: Currently the only know MSSCCI products for Mercurial are Visual Studio plugins that will not work with PowerBuilder.