Re: Subversion and RPG source change management

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