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



From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/24/2010 06:10 PM
Subject: Re: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx



I've just been reading a tutorial on Subversion which discusses the
relationship between repositories and local working copies; where local
working copies are normally project directories.

I envision project directories mapping directly to IBM i project
libraries, and using CPYFRMSTMF and CPYTOSTMF to keep project libraries in
sync with project directories, and other actions for subsequently keeping
project directories in sync with Subversion repositories, and visa versa.

I actually prefer the classification "project library", in order to
distinguish between "shared" project libraries and "individual" programmer
libraries. In many shops, individual programmers will "check out" source
from shared project libraries. Then after source changes are made and
tested, members are "checked in" to project libraries. The check-in event
would probably be a good time to commit changes to the project libraries,
back to the Subversion repository, too; where Subversion keeps track of
revision histories.

Flows might occur as follows:

Repository <==> Project Directories (IFS) <==> Project Libraries <==>
Programmer Libraries

So you might have one set of actions for individual programmers to check
source files, and another set of actions to keep project libraries in sync
with repositories.

-Nathan.



----- Original Message ----
From: Mark Murphy/STAR BASE Consulting Inc. <mmurphy@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Mon, May 24, 2010 12:17:01 PM
Subject: Re: Subversion and RPG source change management

I strongly agree with this. SVN documentation calls this a working copy.
The master is in the repository, and is not maintained directly by
anything. This keeps it safe. Anyone can synchronize their working copy
with the repository to get the latest version of the software. Unlike
tools like Aldon, check-in does not remove a piece of source from the
working copy, so you an always work from where you are, and when ready
update the repository. What you would need is a custom option for PDM
that would compare the source in your working copy with the repository,
and then let you know what is out of date. That tool could also allow you

to update your working copy from the repository to get the most recent
updates from the repository.

This is really a different way of thinking about development from what we
are used to. With SVN you don't check out a program into your development

library, update it, and then check it back in (which removes it from your
development library). Instead, you have all the sources in a development
library, and the production source is in the repository. As folks work on

individual sources they check the in to the repository which updates the
version number for the source, and updates the data store in the
development library that tells the version number of each source along
with some other info about the source. When you are ready to move
something up to production, you check in the relevant source, and create a

tag. If you are working multiple releases concurrently, you may need to
use branches to keep each development effort separate until it is ready to

be merged into the trunk, and then moved into production.

If you look at a SVN client, you will notice hidden files in the
directories backed up by a SVN repository. The hidden stuff is in the
.svn directory. It tells key information about everything in the
directory with respect to SVN. Odds are we are going to have to do
something similar, but keep it in the IFS. We are going to have to build
a SVN client for green screen with hooks into PDM.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx