Using SVN as source control for Sybase PowerBuilder

This article in short describes an idea how to use SVN for Powerbuilder to improve the development process. This solution is based on previously used CVS (described in another article).

We had been using CVS for about 6 years and it was working perfectly.
But currently we have to change the 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 full rebuild failure, PBLs were completely broken).
• Object sources saved in PBLs are not easily comparable.
• Also built-in support for inefficiencies (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 source synchronization (you can use many utilities, but it was always hell after one week tracking all changes and putting them together - it took about half a day per week and it was quiet often that some changes were lost).

Solution

• 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 differences 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 scratch (PowerGen can resolve all dependencies 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 refer to the default location).
• Install module mod_auth_sspi.
• Download and install SVN. You have to choose the 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/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
LoadModule sspi_auth_module modules/mod_auth_sspi.so

<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"
</location>

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 consists of three subfolders, no sources should be committed 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

MyProject
  +-- 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 the 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 comments 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 a single transaction. In history, you can later see all files checked in as a single commit.

Benefits

• 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 made the change and why.
• 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 source 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 committing changes to the tag folder.
• Second which takes commit messages formatted in the same way as in CVS which exports information to the proprietary 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.

Links

• TortoiseSVN
• WinMerge
• Sybase Power Builder on Wiki
• PowerGen
• CVS and PowerBuilder
• CaptainHook
• Apache
• mod_auth_sspi