Yep, the ideal way to do this is to use the SVN repo as the base and
check out members and commit them back to the repo from whatever library
they get checked out into. That would mean tracking repo info for each
source member checked out.
I think it could be relatively usable in the green screen environment
which is why a methodology would need to be created to handle the
checkout to IFS and add to source file and then convert back to IFS and
re-commit when source member is updated.
I've come up with a sample repo model where each source file exists as a
subdirectory in the repo. With this structure it would be easy to mark
an entire library release version or do tags and branches if needed.
Ex: LIBRARYX
tags
branches
releases
trunk
QCLSRC
MBR.CLP
QRPGLESRC
RPGPGM.RPGLE
The thought would be this same repo model could be used to check out the
source members for use with WDSC/Eclipse/Whatever as well as pushing to
a source file for green screen editing with SEU.
If you hooked into SEU/PDM you would probably have to think in terms of
committing individual source members as opposed to entire projects like
we do with Visual Studio and Eclipse although even there you can commit
individual members.
In terms of source type, the file extension in the repo could possibly
be the source type and would have some sort of mechanism that stores the
source member header in the source member so if a source member is
checked out of SVN, the source descriptions could be maintained and set
for the SEU source members when reconstituted into a source file for a
build.
For a production build of an entire library my thought was that you
could have a GET operation that gets all the current source members from
a selected repository, refreshes the build library and then does a
build.
More food for thought.
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
------------------------------
message: 5
date: Thu, 13 May 2010 17:16:16 -0600
from: "Dan Kimmel" <dkimmel@xxxxxxxxxxxxxxx>
subject: RE: Subversion and RPG source change management
To use SVN, you don't want to keep a copy of all your software in source
files on the i. You want to keep the master copies of your source in
SVN. The source in a source file member to be maintained with SEU would
be a working copy. There would also have to be another copy parallel to
the source file member that would be the base copy. The base copy must
be unchangeable except by SVN. An SVN commit does a diff between the
working copy and the base copy and puts that diff to the SVN repository
while also replacing the base copy.
I don't think it would be very usable in green-screen development. It
works great for all the IDE's including Eclipse and Visual Studio. (On
the other hand, there's probably plenty of installations maintaining
source in stream files using VI with SVN.)
One could use an SVN client in PASE or QSHELL for doing the updates and
commits. The developer would have to do the checkout then copy the
stream file from the SVN working copy directory in the IFS to a source
file, use SEU to modify the source, copy the source back to a stream
file in the SVN working copy directory and then do the commit. This
could be automated, of course. Somewhere along the way, the program
objects would have to be built. SVN does diddly about the program
objects.
midrange.com
