Re: Subversion and RPG source change management

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