1. Cyndi Harris
  2. PowerBuilder
  3. Wednesday, 9 October 2019 14:54 PM UTC

We recently upgraded to the Powerbuilder 2019 from PB 12.5. We also have increased the number of developers and would like to use the SVN feature with PB 2019. We found instructions on how to set this up (using instructions for PB 2017 R2 You tube videos - I was unsuccessful in finding any tips, tricks or instructions using PB 2019). We were successful in setting up our repository, having other developers connect to the workspace and even make changes and commit those changes so other developers have access to those changes. We have Tortoise SVN.

Our problem stems from understanding the proper steps with building and deploying the changes so users have the latest changes in the application. The instructions I found did not take things that far. As a rule, we typically rebuild individual pbls and run a .bat file that  copies the pbds to a network drive, overwriting the ones that are there. In an additional step, it copies the entire contents of the developer's working directory to a separate network drive location. Although this was a primitive type of source control, we could roll back to any particular version and have the complete set of code including pbl, pbd, workspace, etc for a developer to use to roll back if there was an issue with a new version. The users have a launch.bat file that runs when users launch the app from a desktop icon. This copies the latest pbds and dlls to the users local drive from the above mentioned network and runs the exe file. We don't create a new exe every time we make minor changes to the application, so we don't use the deploy from the PB IDE every time we make a change. We have had issues in the past with this. 

Powerbuilder SVN does not upload changes to pbd and pbls to the repository. When developer A makes changes and saves them with SVN Commit in the PB IDE, it saves the source and objects, but not the pbl and pbd. When developer B pulls the latest with an SVN Update from the PB IDE, it does not get the new pbd for their working directory.  That developer would then need to look and see which pbl(s) was updated since the last time he got changes from SVN and rebuild that PBL(s) along with their own changes before they run the .bat file to copy the pbls to the network. Our application has 28 pbls, some of them have hundreds or even thousands of objects, so it is not practical to rebuild all of them each time we pull the latest from the repository.  We had an issue where a developer got the latest from using SVN Update, made changes, committed them, rebuilt his pbl, placed all pbds in the network drive for the users.  When the users launched the program, they started having issues with areas of the code that use data stores. (neither developer made changes to affect the data stores or those objects). the funny thing is that even attempting to run the previous version (although we have this is in SVN, we still have the copy of the workspace to the network going until we are sure this works). The previous copy that worked perfectly the last few days now had the same error that the newly published version had. We were unable to run the program successfully without the error from the network location that had the full source, pbd, exe that previously worked. We ended up having to change the data store from using field names to using indexes, rebuilding those pbls and pushing out those changes. Again, none of the changes made recently had anything to do with modifications to the datastores in the pbls. Also while working on this, PB IDE kept crashing while he was trying to debug the program to determine the problem. 

What are recommended steps for a developer to take when making changes, saving them, committing them, rebuilding the changed pbl to make this work? Should we change our .bat file to only copy the pbd if it is newer than the pbd on the network drive instead of copying all pbds? What are the steps we would need to take to roll back to a previous version if there is an issue? What mix of steps are necessary for these to happen? I assume we would use some of the steps within the PB IDE, but since there appears to be a gap in what the PB IDE can do for true source control, we would also need to use the tortoise SVN for other things. I don't think if we use Tortoise SVN for steps to commit changes to pbds, that the PB IDE will recognize those changes when we do SVN Update. Is there anywhere with complete recommended steps to handle source control with SVN with PB 2019? 



Michael Kramer Accepted Answer Pending Moderation
  1. Wednesday, 9 October 2019 19:16 PM UTC
  2. PowerBuilder
  3. # 1

I hear you! Loud and clear.
Unfortunately SVN specifically is not my strength. Too little real-life experience.
So I hope others chime in with your requested info.

HTH /Michael

However, your scenario had me reflect on PowerBuilder's source control and how we as community share learnings.

I sense both curiosity and uncertainty in this community about "native source control" which is markedly different than the legacy MSSCCI based source control.

With MSSCCI there is like 20 years of collective experience. Lots of guidance from prior success/failure with similar tool combo. Unusual combos are tricky but in general lots of relevant guidance.

Microsoft retired MSSCCI a long time ago so "native source control" is independent. Check!
Appeon includes BOTH central version control (SVN) and trendy distributed version control (git). Check!

Both styles are new in PowerBuilder IDE so "we the community" have to learn collectively the good, the bad, and the ugly of how to do native version control. And we fail as community unless we share.

Our insights simultaneously provide Appeon guidance on where improvements provide significant benefits.

The DevOps request for more and more automation only adds complexity on top of source control. So more chances of getting something wrong. Hence, more shared learning required.

I currently worked in an environment where git is the de-facto standard so I invest time and energy in learning that tool combo. Coming from several years with TFVC I also happily join in on TFVC when such integration arrives.

This hopefully allows other MVPs and community in general to share SVN learnings.



There are no comments made yet.
Mariano Collado @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 9 October 2019 17:28 PM UTC
  2. PowerBuilder
  3. # 2

Hi Cyndi,

Other than a few minor improvements and bug fixes, source control in PowerBuilder 2019 works essentially the same as it did in PowerBuilder 2017 R2.

Source Control Enhancements in PowerBuilder 2017 R3
Bug Fixes for PowerBuilder 2017 R3
Bug Fixes for PowerBuilder 2019

If you haven't already, please take a look at the Source Control and SVN resources below:
Overview of New PowerBuilder Source Control Support
Using SVN source control system
Setting up SVN

PB 2017 Git & SVN

There are no comments made yet.
  • Page :
  • 1

There are no replies made for this question yet.
However, you are not allowed to reply to this question.