Re: Subversion and RPG source change management

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.




----- Original Message ----
From: Mark S. Waterbury <mark.s.waterbury@xxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Wed, May 26, 2010 9:53:42 AM
Subject: 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.
.