Re: Subversion and RPG source change management -- MIDRANGE-L

I should have read through all mail first before commenting.... I apologize
for saying you go to a PDM only focus.

Why do you want to create a repository for each library? You can create a
new tree in the repository trunk for every library you need, and just
synchronize that specific subtree with your working copy which is your
master copy.
If you create different repositories you will have to deal with different
revision numbers and non-consistent tagging and versioning between your
libraries.
Regards,
-Arco
2010/5/22 Richard Schoen <richard@xxxxxxxxxxxxxxx>

3rd reading first :-)

No, I'm not focusing on SEU only. Focusing on SEU Editing or RDI
editing so OLD and NEW guys can use this conceptually. PDM would simply
be the master source member location and also where editing process
starts and ends for SEU or RDI. SVN would get the changes when a daily,
hourly or individual source member commit is run from PDM. Remember PDM
options can also be triggered from RDI which supports my concept of
source files being the master location.

IFS would mainly be used as the initial checkout staging area before the
source member gets put into a source file on checkout. IFS would also
serve as the commit area for checking in changes. In my world I would
visualize this as a temporary working area for source members for
checkout/commit processing. It would also know where the repository is
based on the initial checkout operation.

Speaking of repositories: Sourceforge or whatever can be your repository
hoster of choice. You would initially set up a repository to mimic your
source file structure for a library and check it out. From then on you
are connected to the right repository any time you
add/commit/update/revert etc..... So as you suggest the repository and
iSeries locations are separate yet together :-)

For deployments I would probably write a refresh or get from repository
option at some point that works kind of like you've described below. Get
me the current version of all code from this repository and bring back
into my Master source file. Of course you would always commit current
changes first :-)

Think of it like each library has a repository (with a directory
structure that mimics source files such that an entire library can be
tagged, versioned or branched), a temporary IFS structure to handle
checkouts, commits, etc and the library itself and the source files
within the library.

Need some validation that this makes sense before I do much more as this
is a change from my original thought process :-)

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: 6
date: Fri, 21 May 2010 12:55:28 -0600
from: Pete Helgren <Pete@xxxxxxxxxx>
subject: 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?)

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.