Enhanced Source Code Control for PB2017 R2/R3

PowerBuilder R2, released in January 2018, added native support for both the Git and SVN (Subversion) source code control (SCC) software. This native support, where PowerBuilder interfaces directly with these popular SCC systems using their native APIs, allowed PowerBuilder to support more SCC features as well as realize much faster SCC performance and reliability. SCC can be accomplished without requiring the TortoiseGit and TortoiseSVN client software, but to get the full benefits of Git or SVN we recommend installing and using the appropriate Tortoise client software.

PowerBuilder 2017 R3, scheduled to release in the summer of 2018, adds support for additional native APIs of Git and SVN (i.e. more SCC features in PowerBuilder) as well as some usability enhancements. The new features and enhancements include: difference comparison, logging, locking (SVN only, but this is not really needed for Git – more on that in a future blog), support for OrcaScript compiles via Git/SVN, and no longer needing the PBG file (PB’s legacy SCC mechanism). These new SCC features and usability enhancements greatly improve developer productivity when using PowerBuilder with Git or SVN.

It worthwhile to point out that Git and SVN are not the same SCC architectural wise. In a nutshell, Git architecture is based on a distributed approach while the SVN architecture is based on a traditional centralized approach. While both Git and SVN overlap in solving SCC problems, there architectural differences poses trade-offs. A centralized approach like SVN can make administration of the SCC much easier to manage versus Git, but at the cost of some developer productivity and flexibility.

On the other hand, Git allows multiple developers to work on the same object, branching and rewriting history, and offline development, just to name a few of its highlights. However, this comes at the expense of having to merge changes across local developer repositories due to its distributed nature, which under most circumstances TortoiseGit can automatically resolve for you should it happen.

Git is the source code version control system that is rapidly becoming the standard for Microsoft as well as many public (e.g. open source) projects. This was highlighted in 2018 with Microsoft’s acquisition of GitHub.  Also, a number of other popular SCC systems now support using Git as the SCC repository.  In fact, the default configuration now for TFS is using Git (rather than TFVC) as its repository.

One major difference between Git and any other SCC is the way Git thinks about its data. Conceptually, most traditional SCC systems store information as a list of file-based changes. These other systems think of the information they store as a set of files and the changes made to each file over time. Git thinks of its data more like a series of snapshots. Every time you commit the state of your project, Git basically takes a picture of what all your data looks like and stores a reference to that snapshot.

The key when deciding to utilize either Git or SVN as your PB project’s SCC is that you really need to learn the trade-offs of the underlying design and the quirks of the implementation to best support your SCC objectives. To be up front – each SCC, no matter Git, Subversion, TFS’s TFVC or whatever SCC you might choose will have its pluses and minuses. SVN has the advantage as being MUCH simpler to learn since it is based on the traditional centralized approach: there is your repository, all changes towards it, if you know how to create, commit and checkout and you're ready to go and the developer can pickup things like branching, updating, etc. later. Git has the advantage that it's MUCH better suited if some developers are not always network connected. Also, it's much faster than SVN and is able to handle branching and merging (at least for PowerBuilder projects) a lot better.

To this end, I’ll try to highlight some of the various aspects of each SCC, as follows:

Git should be used if …Here are some key considerations for the use of either SCC system:

• You don’t want to be dependent on a constant network connection in order to work on all parts of your project
• You want to protect yourself from a loss or malfunction of a centralized repository
• You don’t need read or write permissions for special directories
• You are interested in quickly transferring the changes made to documents or files
• There are multiple independent groups of developers that can contribute to the project
• Its difficult to provide all developers with fast network access

Subversion should be used if…

• You need path-based access rights for different areas of your project
• You wish to bundle all your work to one centralized repository
• You’re working with many large binary files
• You wish to fully register the structures of empty directories (Git disposes of these, as they contain no content)
• All your developers work under single management concept
• All developers can get relatively fast access to the centralized repository 

As you can now probably notice from the above information, the choice between Git or SVN or any SCC for that matter can be a tough choice.  This get more complicated when you have to consider the perspective of the various players, such as the developer, the IT manager, and senior management.  A short laundry list of things to consider is: SCC use across various projects, inside vs. outside development resources, integration with other SCC tools, reporting, operational stability, ease of upgrading, performance, security, and so on.

The important take away from this blog post is that PowerBuilder is even better equipped in recent releases to support your SCC endeavours when deciding to move towards the newer SCC technologies like Git or SVN.