Re: Subversion and RPG source change management

That's a good starting point. An option to save the sourcemember text is to
use SVN properties. This is the recommended SVN way to register metadata of
files.
However there would still be a problem when you want to checkout directly
from an SVN repository to i Projects in RDP / RDI / WDSC. I think that it
would not be possible to support both, due to differences in handling of the
metadata.
Regards,
-Arco

--

2010/5/14 Richard Schoen <richard@xxxxxxxxxxxxxxx>

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.