Using SVN as source control for Sybase PowerBuilder

· Read in about 5 min · (912 words) ·

This article in short describes an idea how to use SVN for Powerbuilder to improve development process. This solution is based on previously used CVS (described in another article).
CVS we were are using for about 6 years and it was working perfectly.
But currently we have to change hardware and operating system it was running on, so we decided to move forward and use a bit better but still free solution - SVN running on Windows.

PBL problems

The main difficulty of the Sybase Power Builder is in PBL libraries. PBL libraries are binary libraries containing both - sources and precompiled sources.
This solution causes many problems:

  • PBLs are also very inclinable to faults (in Power Builder 7 it was not very surprising that after fullrebuild failure were PBLs completely broken).
  • Object sources saved in PBLs are not easily comparable.
  • Also built-in support for inefficiency (sources are checked-out to temporary PBL library, offline access is not very comfortable etc.).
  • In the case of multiple developers working on the same project this causes many problems with sources synchronization (you can use many utilities, but it was always hell after one week track all changes and put them together - it took for about half a day per week and it was quiet often, that some changes were lost).


  • Use SVN as source control (you can use both *nix or Windows platform).
  • Use TortoiseSVN (or any other free SVN GUI clients) for access to sources.
  • Use Winmerge or any other free utility for sources differencies comparison.
  • Export all sources into SVN project source tree (the best way is to export every PBL library into the separate directory in the SVN source tree).
  • On building machine use PowerGen for project compilation and PBLs restore. In each build you can take your PBLs from the scratch (PowerGen can resolve all dependecies between objects and import them back into PBLs in the correct order).
  • Every developer takes fresh PBLs after every build.
  • Use existing Windows Domain authentication for access to SVN server.
  • Integrate with current project management system.

SVN server setup on Windows

  • Download Apache 2.2 installation MSI and install it (any examples will reffer to the default location)
  • Install module mod_auth_sspi
  • Download and install SVN. You have to choose correct version for Apache 2.2. I suggest to use MSI installation package, because it will setup all required paths etc.
  • Setup new SVN repository (svnadmin create c:/svnroot)
  • Restart computer, if necessary.

Apache 2.2 example configuration

LoadModule dav_svn_module modules/
LoadModule authz_svn_module modules/
LoadModule sspi_auth_module modules/

<location svn="">
   DAV svn
   SVNPath c:/svnroot

   AuthName "SVN Access"
   AuthType SSPI
   SSPIAuth on
   SSPIAuthoritative on
   SSPIOfferBasic on
   SSPIDomain ourdom.ourcompany
   require group "ourdom\development"

SVN repository organization

The SVN repository is organized a bit differently than in CVS. You can definitely find more details on Google. Below are only some details.

  • Each project consist of three subfolders, no sources should be commited directly under project name folder.
  • branching code means that you made a repository copy to a branch folder.
  • trunk folder - contains sources of the main branch.
  • branches folder - contains branch folders for branch copies.
  • tags folder - contains branch folders for tag copies.

Sample SVN repository structure>

  +-- trunk
  +-- branches
     +-- fixes-1.3
     +-- fixes-1.5
  +-- tags
     +-- build-1.3.1
     +-- build-1.3.2
     +-- build-1.5.1
     +-- build-1.6.1

Editing sources

  • Every developer can take fresh PBLs generated by PowerGen after build.
  • Before change perform Update command on existing object.
  • Import this object from SVN sandbox into your work PBL (replacing existing one).
  • Perform any required changes.
  • Export modified object from working PBL to the SVN sandbox.
  • Execute Commit command on the exported object in SVN sandbox, provide proper comment and send it to the SVN source control.
  • You can also (and I strongly suggest this) perform commit on the entire SVN sandbox - this will send all modified files at once as single transaction. In history you can later see all files checked in as single commit.


  • All sources are stored in plain text (including datawindows).
  • All changes are simply trackable (from Power Builder 9 (?8?) this works much better, because in previous versions Power Builder changes order of methods on every save) - at least you know who and why made the change.
  • You can simply resolve any conflicts (no more hell with sharing and synchronizing PBLs between developers).
  • PBLs can’t contain any old errors from rebuilding etc.
  • You can also connect additional actions to every souce file commit/checkout/tag and automatically connect those into other company systems.
  • You can also use tags and branches for tracking your builds.
  • SVN checkins are tracked as transactions, in history you can directly see all files related to the commit.

Project Management System Integration

I found project CaptainHook on SourceForge which allows exactly what I wanted - creation of SVN server hooks using .NET code. So I made two simple plugins to it:

  • One which disallows commiting changes to the tag folder.
  • Second which tooks commit messages formatted same way as in CVS which exports information to the proprietaty project management system.

CVS to SVN migration

There are plenty of tools available for the repository migration from CVS to SVN. We have migrated a repository which had almost 1GB in CVS without any problems to our new SVN source control including tags and branches including the whole history of changes. Migration was running for about 12 hours.