|By Paul Horan||
|December 1, 2001 12:00 AM EST||
PowerBuilder 8.0 was launched in conjunction with the 10th anniversary of the product and, by all accounts, it has exceeded everyone's expectations (...and there was much rejoicing!). The enhancements in this release focus specifically on three major areas - the Web, EAServer integration, and n-tier development.
The introduction of workspaces and targets, and the redesigned IDE have greatly enhanced the overall usability of the tool, especially with regard to these three areas. However, there was one significant revision introduced in 8.0 that is not getting the press I feel it deserves. The integration with source code control (SCC) providers received a major overhaul in PB8, and every PB shop that is practicing some level of version control will have to understand the sweeping nature of these changes.
Where We've Been...
To understand these changes better, let's first revisit the current "state of affairs" with the SCC providers. Most of the prominent SCC packages on the market today were developed for languages like Visual Basic or C/C++, where the code modules are individual ASCII-encoded files stored on the file system.
A typical software application written in C may consist of hundreds or even thousands of individual files. Keeping track of the various versions of each of these files was the job of tools such as Microsoft SourceSafe, Intersolv (now Merant) PVCS, and Rational's ClearCase products. These tools worked by keeping an archive of all the changes to the files and labeling each revision with a specific marker. When it came time for a "build," you would just ask the SCC tool for a specific version of all the registered files, whether it was the latest and greatest version or a specific "label," then compile and link them into an executable.
Then along came PowerBuilder with its PBL files. Unfortunately, the PB code wasn't stored directly on the file system anymore; it was buried inside a proprietary "repository" of its own. The SCC providers weren't capable of dealing with a level below the file system. Keeping track of the revision history of the PBL file was useless, and the SCC tools couldn't peek inside the PBL to track the objects directly.
PowerBuilder was gaining steam in the marketplace, so there was a great incentive for the SCC vendors to develop some level of compatibility. Their collective solution was to develop custom DLLs that integrated with the PowerBuilder IDE, but they were notoriously unstable and buggy, often leaving the PBLs in a corrupted and unusable state. Clearer heads soon prevailed and the standard Microsoft SCC interface was born.
With this standard API, the SCC vendors no longer had to develop a custom interface for each and every development tool in the marketplace, and development shops were free to select the "best-of-breed" tools for their particular environment. It was now possible to use an enterprise-class SCC tool and track the revision history of each object inside a PBL.
The PBNative interface was still available if a full-blown SCC tool was overkill for a particular project. PBNative is a simple object-locking mechanism that prevents two developers from working concurrently on the same object in the same PBL.
Code Management Architectures
Now that we finally had SCC tools with object-level versioning, the question became, "Where do we put the PBLs?" Several different methodologies emerged over time, each with positive and negative aspects. At first the logical choice was to place all the PBLs containing the registered objects on a shared network drive and set up each developer with his or her own "work" PBL for holding objects "in process." Figure 1 shows a typical setup for two developers (Oliver and Stan) using the shared PBL approach.
The library path for the PEAT application in the main folder would contain the PEAT.pbl and all the PFC libraries. In each work PBL a duplicate application object would exist, but would have the work PBL first in the library path. Stan and Ollie would use the checkout feature (either PBNative or the SCC interface) to mark an object in the registered PBLs as "checked out," and a copy of that object would be placed into their work PBL. PB would store the checkout status information right in the shared PBL, and this status change was immediately visible to any other developer who shared those libraries.
At check-in time, the changed object was copied back into the shared PBL, and the copy was deleted from the work PBL. If an SCC tool was being used, a new revision number would be generated and the prior version would be placed in the file archives.
This approach worked well, until Stan happened to be running or debugging the app when Ollie wanted to check in an object. As soon as Stan launched the debugger, PB would place a "write lock" on all the shared PBLs in the application path, effectively shutting down all attempts to check objects back in. The result was often a cryptic "File I/O Error" message, half checked-in and checked-out objects, and several smashed keyboards. As development teams grew larger (and the debugger became more functional) this methodology rapidly fell apart.
To get around this issue, a new methodology evolved that had each developer working with a complete set of all the registered PBLs, including the framework layers, on their local machine. The registered PBLs were still on the network, but the only access to these PBLs came at check-in/checkout time. Developers were still responsible for checking out from the network PBLs, but the library paths pointed only to the local PBLs. Since the network PBLs were not in the library path, there was never an issue with write-locking PBLs during the debug process. Figure 2 shows a typical setup for the "local PBL" architecture.
This process was slightly more complex. If Stan wanted to check out an object, he would:
- Open a Library Painter and navigate to the PBL containing the registered object
- Select Source -> Check Out, and select his own local work PBL in the Checkout dialog; in this case, the PBL is named E:\PEAT_Project\Source\Work\_stan.pbl
- Edit the object locally in _stan.pbl while connected to the local application path
- Check the object back into its original location on the M: drive, releasing the checkout lock and deleting the object from his local work PBL
- Resynchronize his local PBLs with the shared PBLs
That final SYNC step was a new requirement when using local PBLs. Because the check-in process deletes the local copy of the object from the work PBL, the developer's own local code would be out of sync. In fact, each developer on the project would also have to sync periodically to get newer versions of objects. That's why the SYNC tool became so critical. You could set up Sync instructions (.syc files) that examined the shared PBLs and copied any PBLs with changed objects back onto the local workstation.
However, problems with this approach soon surfaced as well. I can personally recall several instances in which I mistakenly checked an object out from my local drive instead of the network PBL. I made my changes, tested them successfully, checked it back in (into my local drive) and then did my SYNC, completely wiping out all my efforts. In addition, the .syc files were static - changes in the application paths were not automatically reflected in these files, adding to the configuration problems. But the primary architectural issue still remained - source control status information was being stored in the PBL, making it nontransportable and fragile.
Obviously, something needed to be done. And with PB8, something most definitely was done. Let's examine the architectural changes that have been introduced in PB8.
There Is No Spoon
If you've seen The Matrix, you may remember the scene where Neo is attempting to bend a spoon only with his mind, and gets some wise advice from a young boy. He's told, "The key to bending the spoon is to realize that there is no spoon." Once Neo gave up his preconceived notions of reality, he was able to achieve great things. Not to be overly dramatic, but PB developers working with SCC tools also have a preconceived notion that the PBL is the repository of our PowerBuilder code. It's not. With PB8, the PBL can be thought of as nothing more than a "receptacle" for our code, holding it while we edit objects, debug applications, and compile executables. Outside of these events, there's absolutely no reason for PBLs to even exist. With the addition of tools such as PowerGen from ECrane Computing, it's possible to completely reconstitute a complete set of PBLs from exported source code files, which is exactly what the SCC tool is tracking for us. It's the SCC repository that holds our code and provides us with any version of any object that we have registered.
SCC Architectural Changes in PB 8.0
The following list of items details each of the major revisions to the architecture of the SCC interface.
Remember, the SCC tool is now the repository so only local PBLs are required.
PowerBuilder now uses the SCCQuery() API call to query the SCC provider for object status information. This is far superior to the inefficient network file I/O that was used previously.
These appear just to the lower left-hand side of the standard object icon, and indicate the SCC status of the object (see Table 1).
This eliminates the .CFG files of the prior versions. The new Workspace Properties dialog (see Figure 3) shows the various options that are configurable for the entire workspace. These include the Project/Subproject name and the rate at which the IDE will refresh itself with object status information.
It's now possible to check in/out objects from different PBLs from the same target in a single operation. Notice the green dot next to the PEAT target in Figure 3. This indicates that the target file (peat.pbt) has been registered and is under source control. Figure 4 shows a dialog that appears when you select the target file and perform an SCC operation on it. PB needs to know whether you intend to work on the target itself - adding or removing libraries from the path - or on any number of objects within the target. This allows developers to work on either the target or to operate on any number of objects within the target.
Checked-out objects are now edited "in place" in the local source PBL. This is difficult to get used to at first, and some developers may still prefer to take the extra step of manually copying checked-out objects to a work PBL, simply to have them all in one place. Remember that to edit the copy, the work PBL must be in a target of the workspace, and the copy must be replaced in the original source PBL before it can be checked back in.
This allows developers to check out objects to their laptops and work on them while disconnected from the SCC repository. When working offline, status information is cached in a new .PBC file on the local machine. Offline mode also enforces the read-only status of registered objects that are not checked out.
Changes in PBNative Source Control
PBNative was introduced into PowerBuilder as way to control concurrent access to objects without the cost and procedural overhead associated with full SCC providers. The PBNative interface remains in PB8, but it was rewritten to be an SCC-compliant provider. In fact, to implement the SCC redesign the old PBNative had to be completely scrapped. There will be a few procedural changes for shops that wish to continue to use PBNative as their sole method of source control.
Since the status information is no longer stored in the PBL, and there's no SCC repository either, the status information is stored in .PRP files. These must be stored on a shared network drive. The PBNative configuration dialog (see Figure 5) records the user name and the name of the network directory that will store the archive files. Registering objects under PBNative will export the corresponding *.sr* files, as well as a *.prp file for each object.
When looking at the files that are generated out to the network archive directory, I discovered something that looked peculiar. When registering objects using PBNative, it seems to truncate the first character of objects in other folders. For example, I registered the m_frame menu object in the pfewnsrv.pbl, and it created files named "_frame.srm" and "fewnsrv.pbg". I was able to check in and out, even with the truncations, so I decided to perform a little test. I created a menu object named x_frame in a new dfewnsrv.pbl. Sure enough, as soon as the new object was created, PB thought it was registered to PBNative. I couldn't check out either object because of the naming conflict caused by the truncation of the leading character.
Most of the more popular SCC tools ship with a "visual diff" tool, and selecting the new Entry > Source Control > Show Differences... menu option in PB8 will use that tool by default. PBNative doesn't ship with a diff tool, so one must be configured in the advanced properties dialog of the Workspace properties window.
The fact that PBNative maintains any revision at all is an enhancement over prior versions. Keep in mind that these archive directories for the project are now a critical component of the project, and their integrity must be maintained.
Some steps can be taken to help ensure success in migrating to a source-controlled environment with PB8, and most of them center around the structure of the project directories. Here are a few recommendations for those using third-party SCC tools with PB8.
Now that each developer has a full set of PBLs on their local drives, keeping the structure consistent across each workstation will alleviate a number of headaches. One requirement for PB8 is that all targets that are under source control within a single workspace must reside on the same hard drive. You can't have one PB target on the D: drive, with the remaining PB targets on the C: drive.
I've seen projects that placed the PFC/PFE layers in a single folder, and then placed all 20 application-layer PBLs in a single folder. This is not an optimal architecture for using SCC management. The best practice is to place the workspace file (*.pbw) in the root directory of the project, and then place all the PBLs in subfolders below that root. If one PBL per subfolder seems extreme, arrange them into logical groups of three or four per folder. The SCC tools will manage the object archives in a folder structure that matches the folder structure of the local drive.
This new option allows an entire Web target to be re-created from the SCC repository onto the developer's local project path. This feature is currently not available for PB targets, but is planned for a future revision of PB. In the meantime, simply copy the PB* files onto the new workstation with XCOPY, then open the workspace in PB and set the SCC connection properties appropriately.
This article has outlined the revisions to the SCC interface that have been introduced in PowerBuilder 8.0. With such sweeping revisions to a critical area of PowerBuilder, I would anticipate some hiccups here and there. Rest assured that Sybase is still working on this section of the tool, and there are several enhancements already planned for upcoming point releases. In future articles we'll examine some typical SCC scenarios and focus on the build process.
- Where Are RIA Technologies Headed in 2008?
- PowerBuilder History - How Did It Evolve?
- Creation and Consumption of Web Services with PowerBuilder
- Cloud People: A Who's Who of Cloud Computing
- DDDW Tips and Tricks
- Cloud Expo 2011 East To Attract 10,000 Delegates and 200 Exhibitors
- Working with SOA & Web Services in PowerBuilder
- Dynamically Creating DataWindow Objects
- Cloud Expo, Inc. Announces Cloud Expo 2011 New York Venue
- OLE - Extending the Capabilities of PowerBuilder