Re: Subversion and RPG source change management

You could do that. I haven't decided if that is totally necessary in the
iSeries library environment because ... under traditional iSeries
development, there may be a single development library, or each developer
may have their own library, but since those "working copies" exist on the
same box, it is easy enough to put them all in a single library list
backed up by the QA library backed up by the production library. You then
have all the stuff you need to compile and test the application. In
addition only the changed pieces are there in your library so that the
unchanged stuff can just fall through the library list to the object
closest to production. How do we deal with that in the SVN environment?
In typical SVN environment everything is there in each working copy. I
don't want to build everything, it is way too much. I just want to
compile the parts that have changed. This is making my brain hurt. I have
been in an Aldon shop where each project had it's own delta release, and
associated libraries. That seems to work, and allows maintenance work to
continue within the bade environment. Once the project is finished, the
delta is merged back into the base environment, and we then are ready to
distribute to production systems. This seems to work better than all the
work happening in a single environment. Development in a single
environment causes far more dependencies that projects carried out
independently of each other.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx



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



Well ... if you believe that branches are necessary ...

Under IBM i, if the need to fork a code base were to arise, with each
branch going off in separate directions, we'd probably do that via
separate libraries, with each having unique names. So maybe we map that to
an SVN repository where additional "library" subdirectories may represent
branches, as an alternative to the structure initially proposed by
Richard, where branches are under libraries. For example:

/svn/product/library/source/member.type
/svn/product/library_1/source/member.type
/svn/product/library_2/source/member.type

where /library_1, and /library_2, may represent branch copies of /library.
In that way, SVN update and commit operations would essentially be the
same for product libraries, and their branches, without broadening the
scope of IBM i procedures that perform SVN updates and commits.

To further that thought, maybe release levels should be moved further up
the hierarchy, instead of under libraries. For example:

/svn/product/release/library/source/member.type

where "/library" maps to an IBM i library, "/source" maps to an IBM i
source file, "/member" maps to an IBM i source file member, and ".type",
maps to an IBM i source file member type (RPGLE, CLLE, etc.).

-Nathan.



----- Original Message ----
From: Mark Murphy/STAR BASE Consulting Inc. <mmurphy@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Wed, May 26, 2010 7:14:46 AM
Subject: RE: Subversion and RPG source change management

Here is why I believe that branches are necessary and desirable. Say you
have a large application, Subversion calls it a project, but in the i
world we call it an application such as a retail application. This
application may have multiple modules, and the group developing it may
have a half dozen developers or more. If the group is large enough, there

may be two or more projects going at one time, plus fix work. If there
are no branches, then only one developer can work on any given project
because only that developer has the appropriate working copy. Or the
projects and even the fix work must be done serially. Now in my
experience it is impossible to determine at the beginning of a group of
projects which will get put into first unless the projects have
dependencies between them. In fact it is impossible to state emphatically

whether any given project will be put into production at all when it
finally comes down to it. I am sure we all have had projects
reprioritized or cancelled mid stream. If all that work is done in the
trunk, then any commits done will go into production all at once, ready or

not. This could lead to a bad situation, or at a minimum it could cause
extra work trying to determine what pieces to add to the tag, and what
pieces to leave out.

To finish that thought, while I am working on a project it is critical,
unless I am the only developer working on that project, to perform regular

commits to allow the rest of my team that is on the project with me to
have visibility to my changes. If these changes are not yet production
ready, then they should not be committed to the trunk because the trunk
needs to be production ready at all times. Fixes are made and committed
there to be promoted immediately.

You cannot totally discount promotion to production because that is what
development is ultimately all about. While using SVN for source control
will not provide all the features of a change management system, it does
provide the foundation, and if that foundation cannot support proper
change management, then it will not be sufficient for source control in a
team environment. That last phrase 'in a team environment' is key because

in it's absence, dedicated source control tools are not really necessary.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx