The Plastic SCM blog

Plastic SCM & PowerBuilder installation guide


First of all, make sure that the Plastic SCM SCC Plug-in is installed and that your client machine can communicate with the Plastic SCM server.

From Plastic SCM side
You have to adjust the Plastic SCM preferences before start working with PowerBuilder. You must go to Plastic preferences, then click in the "Other options" tab, and enable the option:

Compare file contents instead of using timestamp for 'quick diff'.


From PowerBuilder side
In order to bind a PowerBuilder workspace with a Plastic SCM one, you must right click on the PowerBuilder workspace and then on properties menu option. Then, select the tab "Source control" and you will see a screen like the following one. Select Plastic PLUGIN as Source Control System.

You must also enable the following options:
Perform diff on status update
Suppress prompts to overwrite read-only files


Performance considerations


By default PowerBuilder calls to the SCC provider with file packages. The default value is 25, so if you want to checkin 100 files, PowerBuilder will call the SCC provider 4 times, and will create 4 different changesets.


This is a behavior that we want to avoid, due to our checkin operation being atomic. This value can be changed in the PowerBuilder configuration file (pb.ini), that is placed in the PowerBuilder root installation folder, by default:c:\Program Files\Sybase\PowerBuilder\pb.ini
You must add the following parameter under the Library section:
SccMaxArraySize=X, being X the number of files per SCC call. A good value could be 5000.



Now Plastic SCM and PowerBuilder are configured to work with each other. You can take a look at the PowerBuilder documentation about SCC tasks here

Self documented development through inch-pebble checkins

Developers hate writing documentation. But when you find a weird bug or need to understand why a certain change was done, then you wish you had proper documentation. The problem seems hard to solve. Good comments can help and techniques like diff debugging and proper code review tools can help too. But what every developer does on a regular basis is checking in code to his repository. What if the way in which you check in could help self documenting the code?

Side note: I find the technique I describe here not only good for self documenting changes but also to capture the way in which lead programmers work in such a way it can be used to teach the newcomers...

Read more...

Real Time Web Analytics