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

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