Plastic SCM & PowerBuilder installation guide

Wednesday, May 06, 2009 Daniel Peñalba integrations 1 Comments

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

Dani Peñalba

Yes! I was the first employee to join Codice!
I own the record in number of check-ins to the Plastic repository. And you can find me working on every single area of Plastic.
I'm also a professional guitar player and I like scuba diving, too. You can reach me at @danipen00.

Self documented development through inch-pebble checkins

Friday, May 01, 2009 Pablo Santos best practices 1 Comments

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...

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.