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

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