Re: Subversion and RPG source change management

The problem is, SubVersion is just a tool -- and there are many different methods or approaches to exactly how you want to apply that tool to the task at hand -- namely, how you want to manage your source code versions.

Much of the debates I see in this thread recently are really taking about the methodology for how you want to try to use SVN to manage "native" i5/OS source code (in source physical file members).

Not only that, but many are also starting to touch upon other "issues" such as "builds" and "moves to production" -- those are really "change managenment" issues that have little to nothing to do with source code version control ...

The original design goals for SubVersion was for open-source projects where you would have many developers from all over the world, in different time zones, etc., all collaborating and working on the same original set of source code. The idea is, they could check-out their working copies, then make whatever changes they want to, without "locking" any of the original source files, so that others could also be working on changes to the same files, and then, the first one who checks in their changes "wins" and anyone else needs to "merge" their changes. This can be quite "tricky" if the other person happens to change the same range of source statements (lines of code) ... :-o SubVersion provides tools to help with this, and it is not unlike using the MRGSRC command (part of PDM).

The "big idea" is, they want anyone to be able to go off and work on their own enhancements to an open-source project, without impeding anyone else's progress. You must "pay the piper" eventually, and in SVN, this happens when you try to "commit" or "check-in" your changes, and you must deal with merging with any other changes that may not be compatible. The other way to deal with this is, each developer can check-in their own "branch" which essentially "forks" the source tree, and so, they simply defer the task of merging with any other branches or the trunk until some time in the future, or never.

But, is that really how you want to manage your source code in a typical OS/400 shop (or even an OS/400 ISV)? What SVN euphamistically calls "optimistic locking" is really "no locking at all" -- and this is fundamentally very different from how most OS/400 shops would want to control changes to their source code. Also, I am not sure that this really helps with SOX and auditing compliance, either.

Also, most OS/400 shops have relatively few developers or small teams, so it is not that hard for them to collaborate and coordinate their changes to source so they do not "step on each other" -- that is why most OS/400 change management products support "pessimistic locking" where only one developer at a time can be making changes to the same source file member. It is far easier to make changes to the same source code "sequentially" (one at a time) than having to deal with branching and merging of possibly incompatible changes later on.

Any tool, including SVN, can be abused or misused. It is a question of figuring out how best to apply the tool to the project at hand.

And I have not even addressed the issues to do with the fact that SVN, even when it was "ported" to run "natively" on OS/400, did not really deal with source physical file members, but was only intended to be used for "IFS stuff" -- such as web pages, Java, etc. -- that "lives" in the IFS.

In my opinion, branches are 'evil" and should be avoided at all costs.
.