Large Scale Legacy Powerbuilder with GIT or?

Question

I am evaluating various version/source control options for our legacy Powerbuilder application (in PB11 now, will be migrating to legacy 12 soon). To this point, all the version control with very limited source control has been done in-house where the code can be changed by numerous traveling consultants, but the changes tend to be pushed into the base by certain module code owners. This workflow was okay for a while when the company was small, but as we grew, it became more and more challenging. It is a very large application. I'll give you the numbers just to get an idea of the scale we are talking about. Up to 40 PBLS with hundreds of objects in each. About 500MB of code. About 100 consultants constantly on the road, any of them may be making base changes, which are then turned over to code owners.

So after reading about and evaluating various options, I was really excited about Distributed Version Control Systems. I was even more excited when I found that there is actually a proxy GITSCC, made by PushOk to get Powerbuilder to work with GIT. When I tried it out with a small application, I was pleasantly surprised that it worked and worked relatively well, except for some quirks. However what was interesting/disturbing is that I can't find a single post on the net of anybody talking about using GITSCC with Powerbuilder. Even the PushOK's GITSCC forum had only one post (non-Powerbuilder specific) until I created two more. However, once I put our main application under GIT using GITSCC, I noticed major performance issues updating PBL statuses.

So now a couple of questions, which I hope someone can help me with:

1. Is there anybody who successfully uses GIT with Powerbuilder. If so, what's your workflow?

2. When I refresh PBL statuses I noticed that there are two operations, which are very time consuming:

   • The log will say "Retrieving extended status information for the files: . This is performed one object at a time with each object taking about 1 second. As you can imagine we are talking about hours if we are refreshing thousands of objects.

   • Occasionally, I will get the similar behavior, but with the message "performing diff". Same thing - about a second per objects. Takes forever. On the source control tab of the workspace properties, I do have "perform diff on status update" turned off. I do not get this behavior every time, I click on a PBL, but once it starts doing it, you better be ready for a long lunch. Any way to avoid/improve this behavior. This will be a show stopper as much as I loved GIT. I saw some people having similar problems with other source control systems, so I am thinking it's either something to do with Powerbuilder or the proxy. Anything I can tweak in pb.ini or other places to improve the performance?

3. Is there anybody who uses other distributed version control systems? Is there a way to get Mercurial to work with PB? I couldn't find any proxies for it.

4. Finally, is there another system which you think would work well with our workflow?

I tried getting some answers from PushOK, but so far their support has been unresponsive. I also tried the Powerbuilder source control forum, but with so few members in that group, I am hoping to have better luck on SO.

Any help is greatly appreciated!

Answer 1

Finally, is there another system which you think would work well with our workflow?

If you are prepared to look into using Subversion, then Agent SVN is a MS-SCCI plug-in that integrates PowerBuilder and Subversion.

Here is a link describes how it works.

Answer 2

Powerbuilder is notorious for rearranging code in the exported source files. This does not play well with merging in other people's changes in a DVCS. An automated merge has a good chance of corrupting a PowerBuilder export file. Merging by hand is tedious and error-prone with regular diff tools. The only tool I know of that can correctly merge PB Classic files is ProDiff (nee PBDelta). So far I haven't been able to think of a workflow using a DVCS with PowerBuilder Classic that isn't more painful than what your're doing now.