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

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