Re: Subversion and RPG source change management

But, what if you were using something like Sourceforge to store the project? I am trying to understand what role the IFS plays in this scenario.

How I saw it was that the SVN repository would manage storage and change tracking. The local PC would manage editing. (that should pretty much work out of the box right now). What I envisioned for the "build" part was to use something similar to the MyEclipse "Manage Deployments" option. You could define a "Compile Only", an "Update Source", and a "Compile and Update Source" set of options. Compile would do just that. Update Source would take the current source member and copy it back to the "Master" Source member on the i (or may have it both commit AND copy to the source member on the i).

I just see the whole svn side disconnected from the actual i side since the SVN repository could be anywhere. The update of the actual source member would always be a separate step/option.

My 2 cents.

Pete

(On third reading, are you only focusing on a SEU/PDM editing model?)


On 5/21/2010 10:30 AM, Richard Schoen wrote:

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.

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: 3
date: Fri, 21 May 2010 10:20:44 -0500
from: Aaron Bartell<aaronbartell@xxxxxxxxx>
subject: Re: Subversion and RPG source change management

Sorry for the delayed response.

Did you ever do anything with this ?

Mike Wills started putting some stuff together along those lines. Let
me know if you would like the code he sent to me and I will forward it
to you.

Was there a reason other than Java performance why you made the SVN

service a background job ?

Performance. I would love to find a solid set of C based API's that
connect with SVN vs. Java.

Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/