Re: Subversion and RPG source change management

Hi Richard,

I understand your wish to keep the PDM source as Master copy. My guess is
that in the long term this just will break the workability of SVN with i. I
believe the Master source belongs in the SVN repository. Of course you
can keep a Master copy in PDM and update that on a frequently base.
You can have each developer checkout sources to his/her own development
library, do the work there and commit the changes back to his branch or even
the trunk. Once there is a revision tagged for release, you can update your
Master copy in PDM and let it recompile.

By the way, developers can indeed work with RSE to edit sources in the
Master PDM copy, but don't have SVN options available there. The Subclipse
plugin only works on local projects.

When using the IFS as "working copy in the middle" (and there is no other
way I believe) there's also another point to handle. When copying from
source members to the IFS and vice versa you will also lose the fine source
member text description. IMHO it would be best if the handler program that
handles the source copy would also be able to write/restore an SVN property
for that source.

I really don't mean anything offending here, but I see you focus go to just
keeping the main source in your PDM working copy, and only do commits from
there. If that is the goal, then there's not much more additional value for
using SVN than just being a Source Version Archive.
Best regards,
-Arco
2010/5/21 Richard Schoen <richard@xxxxxxxxxxxxxxx>

If you've got some base code for that, it would help my thought process.


I'm starting to think about going down the road of leaving the PDM
source as the MASTER copy of the source much like our current iSeries
based solution.

Then you would simply commit changed source members to SVN on a regular
basis and allow users to commit from or update or revert from SVN back
to the PDM source as needed.

This would allow RDI and SEU users to still use their weapon of choice
quite nicely and the source would get managed by SVN. RDI users could
still use Remote Systems Explorer and SEU users could use PDM.

It would also allow you to commit from the iSeries and check out offline
copies for use on a local PC as well via Tortoise or your favorite SVN
client if desired or if you're traveling.

One interesting thing I found is that because of the byte-level change
tracking within SVN you can copy from a source member to a stream file
and SVN detects whether it really needs to commit changes or not based
on comparisons. The only thing you would lose during commits and if you
brought back a source member from SVN would be the line number stuff,
which quite honestly if you use diff to look at source changes should
not matter anyway for modern developers :-)

So as an example: Let's say I store all my source in source files on the
iSeries as a base. Now I want to commit the changed or ALL members to
SVN. I would simply run a process to go through and put the current
source members to a working checkout folder in the IFS and call SVN
commit. Only members that actually have changes would get committed,
thus allowing SVN to do what it's good at while I maintain the source
MASTERS within PDM.

The second benefit of this strategy is that my regular SAVLIB/SAVCHGOBJ
methodology would still backup source the iSeries way to complement my
SVN archives.

I think for the most part calling a single COMMIT Java command to commit
an entire library of source to SVN will probably not be too performance
intensive, so I am favoring the call Java API directly approach,
especially since you could still submit the COMMIT operations to batch.