Not necessarily. If a proper client for PDM was created, the IFS is just
a middleman. It would not be necessary unless you are planning to use an
existing SVN client that needs that particular structure to synchronize
with the repository. A native SVN client for PDM should not need that
artifact.
Do you expect the "source files as masters" to be fully populated with
source files all the time? That is the key to everything working
properly. The reason I don't call it a master but instead a project
library is that the repository itself is the master, and everything else
is a working copy. Just semantics, but as long as the repository is good,
all the working copies can be lost, and you can always recover to any
point. If the repository is lost you can only recover to a point where
you have a good working copy. Unless you save a copy of production source
outside the repository, you can be lost. Master implies that it is the
gold copy, and I really don't want any development being done against
that.
There can be only one! Having two masters can be problematic since one
will evolve as the real master, and the other will become subservient. If
the repository becomes subservient, you can't guarantee that it contains
the master code, and now you have to do extra work to manage it, even if
that extra work is only perceived, then that is a problem. I suggest that
we remove the term master, and use the terms Repository, and Working
Copies. The repository is the safe-house where all code changes are
stored, no modifications are allowed directly against the repository. The
working copies are all other copies of the code. The working copies can
be changed at will, and those changes must be checked in to the repository
to become full updates to the code. That should keep things straight
conceptually for everyone. When promoting to production a tag from the
trunk is created, and that source is then built and promoted to
production. Calling source libraries on the i masters would give the
false impression that a build to production could come from there until a
change that someone made with WDSC or RDi which wasn't in the "master
libraries" got missed because the "master" wasn't synchronized first.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
From: "Richard Schoen" <richard@xxxxxxxxxxxxxxx>
To: <midrange-l@xxxxxxxxxxxx>
Date: 05/25/2010 03:23 PM
Subject: Re: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Actually if you're going to use SVN at all, the IFS portion of the
equation is always needed because it is the middleman between the SVN
repository and source files for an application build.
If you were to use my concept of "source files as masters or what you
call a project library", there might be an SEU command to copy/check out
the source member to your library so you can work on it. Then when you
promote it back to the master source member it could get auto-committed
to SVN.
In our case we use a master library for each product.
Ex: SRCPRDNAM
If each developer could check out (make a copy of) the source member
from SRCPRDNAME to their DEVLIB and then promote it back to SRCPRDNAM
which would auto-commit the member that might be useful.
This same concept could work for RDI or SEU/PDM.
Not sure if that's what you were envisioning.
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: Tue, 25 May 2010 15:03:38 -0400
from: "Mark Murphy/STAR BASE Consulting Inc."
<mmurphy@xxxxxxxxxxxxxxx>
subject: Re: Subversion and RPG source change management
This could be a good way to do it due to the fact that multiple
programmers would be working on the source on the i. At a recent
client, they have 4 environments set up in their CMS. Production, QA,
Integration, and Development. For the application I was working on,
each developer has their own development library, and them moving up to
the Integration environment is where the rest of the team can see the
changes I made. In my mind, this is where SVN comes in. On a PC
development environment, where there is only one developer per PC,
checking changes in to SVN is where my changes are made available to the
rest of the team. So I can envision an environment on the i where a
team has a "project library", and each developer has his own library,
and the process that moves things up to the "project library" also
commits to subversion.
If we were to write a subversion client for PDM, then the IFS portion of
the flow would not be necessary.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
midrange.com
