Re: Subversion and RPG source change management

Another SVN terms issue here. We use Check-out to mean go get the source
and bring it into my development library, and Check-in to mean I'm done
with it, go ahead and put it back. There is member locking and other
things that happen in the process to ensure that conflicts do not occur.
SVN uses Update and Commit. Update merges any differences in the most
recent version of the repository into the working copy, and Commit merges
any differences in the working copy into the repository. Nothing is
locked, thus multiple developers could make changes to the same source and
then both attempt to do a Commit. This can cause conflicts that need to
be resolved manually. I have seen it happen. Automatic Updates and
Commits while attractive may be harder to implement than we want.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx



From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/25/2010 04:50 PM
Subject: Re: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx

From: Richard Schoen
there might be an SEU command to copy/check out
the source member to your library so you can work on it. Then when you
promote it back to the master source member it could get auto-committed
to SVN.

Regarding IBM i specific check-out & check-in procedures, I could see them
operating independently of Subversion's "update" and "commit" procedures.
For example, a shop might have a policy of updating working copies from
Subversion nightly. But during the day, any number of IBM i check-out /
check-in operations may be performed. Where "check-out" copies source
members from product libraries, to programmer libraries. Where "check-in"
copies member from programmer libraries to product libraries AND related
IFS directories. Check-out & Check-in may be interactive. While
Subversion "update" & "commit" might be nightly batch operations.

I envision a set of IBM i tables used by check-out & check-in procedures.
One to record check-out & check-in history. Others for configuration
purposes. More specifically, I envision a product table (student,
finance, community, etc), product libraries table, library source files
table, and check-out / check-in history table. You might use these tables
to indicate mapping between traditional libraries and files, to IFS
directories. In addition to check-out / check-in history, you might also
record Subvision update / commit history.

So tables might be used for configuration, history, and perhaps even
Subversion file conflict resolution; since actual repository
synchronization may occur as a nightly batch process.

-Nathan.