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

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