Many PowerBuilder developers want to try Git as it gains in popularity. However, as PowerBuilder IDE still relies on the binary PBL format instead of directly working with the plain text source code files, the implementation of native Git support comes with some special features that you may need to be aware of in order to use Git properly or to work around some of the limitations. This article tries to give some tips in this area.

If you are not familiar with the basic flow of setting up PowerBuilder with Git, please check this article first PowerBuilder 2017 R2 New Feature: Git source control support. 

#1 The checkout directory has to be created using PowerBuilder

After you have uploaded your workspace using PowerBuilder, another user still needs to use PowerBuilder > Connect to Workspace to download and set up in his development environment. It doesn't work if you simply copy the entire workspace folder over to the other user's machine. Nor will it work if you use a Git client to download the workspace. The PowerBuilder Git feature will only be activated for the other user after he uses Connect to Workspace to set up his workspace. 

Another thing is that as the associated data for the Git settings for a workspace is saved in the registry tied up to the workspace path, The PowerBuilder Git feature will be disabled if you move the workspace to another location.

#2 When to use the Refresh menu item

There are mainly two situations when you need to use the Refresh function. 

• The first time you do the Connect to Workspace to set up your local workspace. 
• After you directly modified the source code outside of the PowerBuilder IDE.

The reason behind this is that PowerBuilder IDE doesn't load the code directly from the source code files. It only displays the code saved in the PBLs. Ideally, PowerBuilder should be managing all the synchronization automatically. The reality is that PowerBuilder only pulls the source code into PBLs when you do a Git Pull. On the other hand, it only exports an object to the source code folder when you save it in the IDE. Synchronization of anything changes that happened in other manners has to be taken care of manually. 

So, as PBLs are only uploaded once during Add to Source Control. The later code changes are not reflected in the PBLs on the server. So the first time you download the code from the server, you need to do a manual Refresh.       

#3 When to use the Upload PBL menu item

Normally you don't need to use this feature. When you do the "Add to Source Control" and do the first Git Push for setting up the repository all the PBLs in your workspace will be uploaded to the server automatically. 

By default, PB will not commit or push the PBLs to the server thereafter; Only the *.sr object source files will be committed and uploaded in later operations. If there are any changes on the server in the *.sr files, they will be downloaded and imported to the PBLs when you do a Git Pull. So it kind like the PBLs are dynamically built when you do a Git Pull. But the dynamical building process requires the presence of a skeleton PBL, which is why the original PBLs were uploaded when you set up the repository. 

Now, there is one situation you do have to use Upload PBL. That is when you add a PBL to the workspace. This is so that your colleagues will be able to get the skeleton PBL when he pulls in your changes from the server. 

Note: Upload PBL doesn't literally upload the PBL. It only commits the PBL and you still need to do a Git Push to really upload it to the server. 

#4 Source control other assets in your workspace

Besides the PowerScript source code, you will probably have other assets like images, icons, external components that you want to commit to your repository. As PowerBuilder Git actions are based on the System Tree, you can't commit these assets from PowerBuilder IDE. You will need to use a tool like TortoiseGit to commit these assets.

Note: When you first create the repository using the Add to Source Control command, it will list all the files in the workspace including the external assets. So you can commit them at that moment. But you will not be able to do any Git action against such items after that.