I also like the source file method because it would let me still use the source file tools we use now to scan code for doing impact analysis. We still use Abstract and I can't tell you the last day one of our developers was not either using Abstract to find something or doing scans of RPG/DDS source code.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Friday, May 21, 2010 10:34 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Subversion and RPG source change
In my thought process the master copies will always technically be in
SVN because you would be committing changes on a regular basis.
Another benefit of using source files as the master is that the
edit/compile/build process would still feel natural to an RDI or SEU
user. I have a hard time picturing check out to PC, edit with RDI,
save to PC, commit, check out to source file, build. Too many steps
unless you can describe a shorter process.
Developers would have access to the SVN options in RSE because you can
create user actions which would trigger CL commands for source
commitment. I would not use iSeries projects because that mechanism is
klunky. Furthermore users would still have to ability to use SVN and
Tortoise if desired to check out individual members to the PC as well.
On the IFS comment I have chosen to write headers to the source members
when first committed or the developer can pre-add them to each source
member. The header has 3 keywords @@MEMBER, @@TYPE and @@TEXT as header
keywords. This will allow source type and text to be automatically
rebuilt on a get or refresh of the source members from a repo. I don't
want to tie this to an SVN property because it could get klunky. Better
to recreate the source member, get the keywords and change source member
properties on a get or checkout.
My focus is to allow the source to be edited and maintained in either
RDI or SEU because we use both and most real world shops do as well.
SVN is a source version archive. That's its main purpose and what we
plan to use it for :-)
Queue David for the Change Management conversation..........
Actually I do want to look into the Rational Team Concert offering as
well. Apparently V2.0 is a little more compelling, however I wouldn't
relish moving all my SVN repositories to it.
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: 7
date: Sat, 22 May 2010 00:56:23 +0200
from: Arco Simonse <arco400@xxxxxxxxx>
subject: 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
midrange.com
