Re: Subversion and RPG source change management

The more I get into the Subversion tutorial, the more I see of value. I personally wouldn't want to rewrite it. I'd prefer to run it under PASE. But if that's not possible, I may break down and get a Linux host. I'm kind of counting on Arco or an AIX expert to come up with installation instructions for PASE ;-)

We're supporting multiple software products (student, finance, community collaboration, etc.). Most of our products have two or more libraries; at least one for runnable objects (*pgm, *srvpgm, *cmd), and at least one for data objects (*file, *dtaara, *etc). Each product may have different release levels, and may not be dependent on another product. I envision separate SVN repositories for each. For example:

/svn/product/library/trunk/file/member.type
/svn/product/library/tag(release)/file/member.type

Where there may be multiple libraries per product, multiple files per library, and multiple members per file; which is essentially comparable to the traditional IBM i library file system. The main difference would be having a directory structure that includes release levels (trunk & tag), which fits right in with Subversion.

We'd need CL commands for check-in and check-out, because we use PDM. But the idea of having RDP user defined options that map to commands, would be appealing too.

-Nathan.





----- Original Message ----
From: Mark Murphy/STAR BASE Consulting Inc. <mmurphy@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Tue, May 25, 2010 1:03:38 PM
Subject: Re: Subversion and RPG source change management

This could be a good way to do it due to the fact that multiple
programmers would be working on the source on the i. At a recent client,
they have 4 environments set up in their CMS. Production, QA,
Integration, and Development. For the application I was working on, each
developer has their own development library, and them moving up to the
Integration environment is where the rest of the team can see the changes
I made. In my mind, this is where SVN comes in. On a PC development
environment, where there is only one developer per PC, checking changes in
to SVN is where my changes are made available to the rest of the team. So
I can envision an environment on the i where a team has a "project
library", and each developer has his own library, and the process that
moves things up to the "project library" also commits to subversion.

If we were to write a subversion client for PDM, then the IFS portion of
the flow would not be necessary.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx