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

> On 5/26/2010 1:30 PM, Nathan Andelin wrote:

Mark,

That was an interesting summary. I'm reading a Subversion tutorial that addresses "lock-modify-unlock" vs. "copy-modify-merge". Subversion went with the "copy-modify-merge" philosophy. You are right about having to pay the piper, one way or the other. In one case you prevent others from modifying code until a lock is removed. In the other case, you require programmers to resolve differences, at a later date. Personally, I can see a place for both.

Your observation about Subversion being designed for around-the-clock open-source development triggered the thought in my mind, that maybe we'd see more open-source development under IBM i, if an interface existed that simply mapped IBM i libraries, source files, and members to Subversion repositories. Let the Apache module enable team members from around the globe to access to a Subversion repository, instead of providing 5250 or RDP access to libraries. You may not want to allow that much access to a loosely structured open-source community.

It seems to me that the wide-spread use of Subversion, and the availability and popularity of IDE plug-ins, in conjunction with an IBM i library/source/member interface could open-up new channels of IBM i application development.

-Nathan.