I agree it will be a lot of work. My comment was more intended on how to still maintain a similar "look" for the developers from the library painter. (If I only thing of stuff like "libraryExport -import").

I am very much in Chris's "If it isn't broke, then don't go fix it" camp. For my shop, it would be a massive headache to reorganize all our applications if PBL files were removed. I have worked in the C/C++ world where we thousands of code files that we organized using separate directories. It worked, but I do not feel that was somehow superior to the PowerBuilder library files.

"pbls used by InfoMaker and also PB Apps add them dynamically" : pbls could be removed as the default storage but still allow pbls, so that the runtime add pbl continues working as well as infomaker.



when using SCC you end up having directory structures that exactly match the pbls, with the pbls in the directory as well as the source in the directory. everything is stored twice :-/



it would be nice to have the pbls gone, but this is very very low wish list item

Hi Guys;

FWIW: I've been using PB since 1989 version 0.8 alpha and have never encountered a corrupt PBL. However, I don't trust SCC alone ... tons of regular incremental file backups too. ;-)

Regards .. Chris

I've seen so many corrupt PBLs. Might've been an issue with the external SVN proxy tool, though. My "favourite" is ghost objects. As in source files that couldn't be compiled but were still saved somehow and afterwards won't show up in the PBL. They're apparently still in there somewhere, because trying to re-import them fails with a message saying the file already exists.



@Christopher: the PB implementation of GIT requires you to push PBLs to the repo at least once. A new folder "ws_objects" is created that mirrors the PBL structure, containing the source files in seperate folders named after the respective pbl. This at least removes the need for pbg-files and makes it easier to move source files to another library.

This enables you to check out a project from GIT and have a working PB workspace right away without having to generate PBLs via orcascript. This is obviously more convenient than previous solutions. But the PBLs will only become more outdated over time unless you update them on the repo on a regular basis. Might not be a problem at all but could well be, in the long run. Especially if the master branch is protected and can't be directly pushed to.



@Armeen it's good to see that GIT support is being improved upon. Keep in mind that merging branches into master might happen outside of PB, though. Like for merge requests with code review.

Chris

You are lucky.