Tech Articles


How to switch from an SCC API SVN client to the native SVN interface


If you have been using the Subversion (SVN) source code control system for your PowerBuilder applications for a while, you have likely been using an SCC API implementation client (such as PBSCC Proxy, PushOK, etc.) to connect PowerBuilder to SVN. If you are considering switching to the native SVN interface provided by PowerBuilder then you probably do not want to lose the history of all the changes you made during all those years of development. Although this is not covered in the PowerBuilder documentation, it is relatively simple to do.

Basic idea

There are only two things that you need to do with your SVN repository to start using the native SVN interface:

  1. Rearrange the source code files the way the native interface expects.
  2. Add a workspace file.

If you've followed PowerBuilder's recommendations, your repository for any application should look something like this:

[application folder]
                [trunk]
                                [main PBL folder]
                                                source code files (*.sr?)
                                                target file (*.pbt)
                                                *.pbg file
                                                ini and picture files
                                [module A folder]
                                                source code files (*.sr?)
                                                *.pbg file
                                [module B folder]
                                                source code files (*.sr?)
                                                *.pbg file
etc.

The native SVN interface uses a slightly different way of organizing source code files. If we want to keep the original folder structure, it will look like this:

[application folder]
                [trunk]
                                [main PBL folder]
                                                target file (*.pbt)
                                                ini and picture files
                                [ws_objects]
                                                [main PBL folder]
                                                                [main PBL folder].pbl.src
                                                                                source code files (*.sr?)
                                                [module A folder]
                                                                [module A folder].pbl.src
                                                                                source code files (*.sr?)
                                                [module B folder]
                                                                [module B folder].pbl.src
                                                                                source code files (*.sr?)
etc.

In other words, the original folder structure is replicated under the ws_objects folder, and folders named after PBL/PBG files that exist under each original folder contain the source code files. Note that the native SVN interface does not use PBG files. Instead, it relies on the *.pbl.src folder names and content to create the PBL files.

So, all you need to do is to move the source code files to the expected folders using SVN commands or a GUI client so that the history of changes is preserved.

Regarding the workspace file, it may seem that the native interface requires the workspace repository folder and the workspace file to have the same name. Fortunately, this is just the way the initial addition of a workspace to SVN works. Connecting to SVN and downloading your workspace from the repository do not have this requirement, so you can give your workspace file a meaningful name and place it directly under the trunk folder.

Demonstration

Let me illustrate the basic idea using the PB examples application. I will be using PBSCC Proxy as the SCC API implementation client and TortoiseSVN as the GUI SVN client. The following is the initial state of the workspace:

And this is how the repository looks:

Step 1. (Optional) Create a new folder in the repository

You can modify your existing repository, but for this demo, I will create a separate branch that is compatible with the native SVN interface:

Step 2. Create the expected folder structure

You can do this either directly in the repository or in a working copy, and then commit the changes. After this step, the repository looks as follows:

The pbexamfe folder on the top level will contain other files, like pictures and the target file.

Step 3. Relocate the files

If you're modifying the repository directly in the trunk folder, move the source code files to the corresponding .pbl.src folders under ws_objects. Since I am working in the branch folder, I will copy the files from trunk using TortoiseSVN:

Step 4. Add the workspace file

Use your existing workspace file, rename it if needed, and upload it to the root folder of your repository (trunk or, as I did here, a branch folder):

If you want to change the default encoding of the source code files from UTF8 to ASCII, add the following line to the workspace file before committing it to SVN:

Step 5. Connect to workspace

In PowerBuilder IDE, right-click the "(No Workspace)" item in the System Tree and select "Connect to Workspace" from the pop-up menu. In the opened window, select "Subversion (SVN)" and fill in the other fields:

Click OK, wait for a bit, and voila! You have switched your workspace to the native SVN interface and kept the history of changes:

Conclusion

This approach works for regular PowerBuilder workspaces, and I used PB 2022R3 for this article. As of this writing, PB 2025 has not yet been released, so I don't know what the repository structure for solutions will look like.

Comments (0)
There are no comments posted here yet

Find Articles by Tag

Debugging Error HTTPClient External Functions JSONParser Variable API MessageBox RichTextEdit Control Excel Jenkins Stored Procedure SVN Validation Linux OS Database Object Migration Script Export DataWindow JSON InfoMaker 64-bit Syntax Debugger Export JSON OLE JSON JSONGenerator Design Testing Application Service UI Database Table Schema Event NativePDF Filter PDFlib Messagging SnapObjects RibbonBar Android 32-bit Model Authentication DLL PowerBuilder (Appeon) DevOps Icon Platform ActiveX SQL TortoiseGit PowerScript (PS) OAuth PBNI SDK CoderObject Configuration GhostScript Database Database Connection Database Painter RESTClient Resize BLOB Import JSON UI Themes TLS/SSL SOAP .NET Std Framework Mobile Expression Encryption PowerServer Mobile Database Table PostgreSQL Elevate Conference TFS Windows 10 Icons Visual Studio RibbonBar Builder Web API Automated Testing Installation XML .NET Assembly OrcaScript Event Handling Azure Trial Bug COM TreeView Data DragDrop Transaction DataWindow Interface SqlModelMapper iOS WinAPI Source Control Authorization SnapDevelop Windows OS ODBC PFC SqlExecutor Debug Sort Deployment Text REST PowerBuilder Compiler C# Charts License Window OAuth 2.0 SQL Server Encoding Oracle Branch & Merge Event Handler Import Class Open Source WebBrowser Web Service Proxy Array Database Profile Performance PowerServer Web CI/CD Git CrypterObject Repository .NET DataStore Source Code PostgreSQL ODBC driver Menu PBDOM DataType PDF PBVM File Graph IDE Outlook PowerBuilder Database Table Data UI Modernization