That does sound nice. I think I would use such a tool. Would it also be able to deal with java source files and keep the master copy in the ifs were we have it now?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Friday, May 21, 2010 12:31 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Subversion and RPG source change management
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/
midrange.com
