Re: Subversion and RPG source change management

Richard already indicated his reasons for continuing to maintain source members in the traditional library-file system. In addition to his reasons, we use a tool that generates CL scripts from database meta data. We have another tool that interpretively runs the scripts and generates Web applications plus related configurations. We also use the RUNSQLSTM command against SQL source members. We're using more tools than just ILE compilers, in summary. We're a long shot from being ready to use the IFS alone for source. I'm interested in using Subversion, and it appears that several others are interested too. So that raises interest in an interface with the traditional IBM i file system.

I wouldn't be interested in a kludgey system either. Regarding the effort that it might take to put one together, that may depend on mutual collaboration. I couldn't predict what might come of that, but the discussion has opened my mind, at least.

My gut feel is that the wheels are turning in the minds of a number of participants here. Someone may be thinking that the job of synchronizing a repository with the library-file system won't be too big, because they've already done work on that. Someone else may be thinking that installing the AIX port under PASE might not be too hard. Someone else may be an expert on check-in, check-out procedures. Someone else on compare & merge procedures.

-Nathan.

----- Original Message ----
From: Mark S. Waterbury <mark.s.waterbury@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Wed, May 26, 2010 11:55:41 AM
Subject: Re: Subversion and RPG source change management

Hi, Nathan:

Thanks for your thoughtful reply.

If the goal is mainly to foster and support open-source development on
IBM i, then I think you could use any standard version of SubVersion. If
you can use a recent AIX SVN under PASE, then you can have all your
source in the IFS. All of the ILE compilers except CL (CRTCLMOD or
CRTBNDCL) allow the source to be in a stream file (in the IFS). So,
then, no need to "mess with" source physical files at all, in this case.

The open-source model, whether using SVN, or CVS, or GIT, etc., follows
a model where you make a bunch of coding changes, compile locally, unit
test, then at some point you "check-in" or commit your changes, perhaps
to a new branch, then you submit some kind of a "build" process that
re-compiles everything, or perhaps uses a "make" tool to only recompile
what needs to be recompiled, based on which source files have been
changed. In any case, this is probably fine for "open source" projects
with developers who are geographically disbursed.

I just don't see it being worth all the effort to try to force some
(kludgy) way to make SVN work with source physical files and traditional
or "native" i5/OS software development. I think it would be a
significant effort to do this, and as I pointed out in a prior post, you
would still lose many of the "features" of OS/400 or i5/OS when working
with source physical files, such as the correct member last changed
dates, etc. unless significant development effort was expended to make
SVN work "natively" with source physical files.

The "Subject" of this whole thread is somewhat misleading -- "Subversion
and RPG source change management" -- I do not think SVN i(or CVS or GIT,
etc.) s a "good fit" for RPG (or RPG36 or RPGLE), or any source that
resides in a source physical file. And, SubVersion, CVS, GIT, etc., are
not "change management" tools, but only "version control" tools, with
the emphasis mainly on source code versioning..

Mark S. Waterbury