Aaron wrote:
I guess I look at it a little differently, but that may be because my
project is on the smaller side. When developing, I am constantly compiling,
running, and debugging my code. Simply being able to select Ctrl+S to get
the source on the i5 is nice, and then I click the compile button in the
header of WDSC (which executes the most recent compile command again) and I
am ready to run/debug the app. If I were to do the same from iSeries
Projects I believe I first would need to sync back up to the i5 and then
compile, is that correct?
I have been experimenting with iSeries Projects and svn. I am the only
one doing this, so the only damages have been self-induced. First and
foremost, I completely agree with Heinz -- DON'T edit your source on the
System i side!
Unless you have a System i green screen svn client and can check out/in
your changes, you pretty much can't tell when collisions occur. Don't
subvert Subversion :-)
On to the actual question, yes. When I want to compile my RPG program
in iSP (too tired to type iSeries Projects all the time) I have to save
the member back to the System i before compiling it. Be advised that
the library the member goes to is your project library, and there's only
one. Let me take a step backward.
When you define an iSP, you tell WDSC what library the project belongs
to. In my case, it's a 'development' library. My actual production
code lives in 3 different libraries, and iSP doesn't deal with that. So
I have to run a 'pre project setup' routine on the System i side to
create my development library, create the source files and copy in the
source members I'll be working on. On the WDSC side, I need to create a
Subversion repository, create an iSP, link the iSP to the svn repository
and System i development library.
Once I start editing, I have 4 copies of the source code:
1) System i current production code in production libraries
2) Subversion repository
3) iSeries project workspace
4) System i 'development' library
Each and every one of these versions is probably different from each
other for a large portion of the time.
1) Using iSP Navigator view, open member for editing
2) Edit member, verify, etc. It won't take long before you want to
compile it so that you can test it on System i...
3) Using iSP Nav, right click member and 'Push'
4) Using iSp Nav, right click member, Remote Actions, Compile
5) Test your code on System i in the development library
At this point you have code at different levels. Workspace matches
Development, but Development is different from both Repository and
Production. You now get to decide if you've reached a checkpoint where
you want to record the changes in the Repository. If so,
6) Check in to the Repository.
Note that it's on purpose that each member is at a different change
level. That's how svn works. Now that you've checked in your code, you
have matched the Repository to Development, and the only member that's
different is in Production.
You keep on going until you're ready to deploy the project to
production. You can right click on iSP Nav at the project level and
generate a COMPILE.CLLE member that you can use as a base to create all
the appropriate objects back on System i. Be sure to copy source back
to the proper production library!
My approach was going to be to do all editing in the regular RSE way and at
the end of the day re-checkout everything back down to the iSeries Project,
and then sync that iSeries Project with SVN. Maybe the better question is
this - what does iSeries Projects offer me concerning program development
outside of SVN interactions?
It's helped my frustration level to recognise that iSP is absolutely not
intended to be a good svn client, nor is it intended to be a good System
i development environment. Its primary goal in life is to allow us to
syntax check code when we are not connected to System i. Like on an
airplane. Trying to make iSP into a source management tool is seriously
twisting its purpose, and it's not a very good fit in my opinion.
I get the feeling I have a triangle here where my PC is at the bottom and I
have SVN off to the left and the i5 on the right. Currently my focus of
where the "prime version" of source is located is to look at the i5, but I
think my focus needs to change to be on SVN, correct? At least that is how
I would do my Java development.
You need to decide where the source of record will be. iSP is not
change management and svn is not integrated into PDM, so anyone who
changes code with PDM/SEU will break the build. There is no knowledge
of the Production library in iSP or svn, so if you decide to keep source
in a traditional library that is a Big Red Flag.
It might be possible to import all your source into svn and the delete
it entirely from all production libraries. You'd still have a
Development library to push iSP source to, but it would be temporary,
and you'd never consider System i to be the source code of record.
Deploying would entail moving the compiled System i objects into the
appropriate production libraries.
Unless no one will ever use PDM/SEU anymore, this is a non-starter for
most companies. Documentation tooling comes into play here as well.
Will Pathfinder or Abstract or X-Analysis be able to traverse a svn
repository to create documentation/cross references? Backup/restore
needs to be considered, as does authority/security to source members.
Hope some of this was helpful. Don't curse out the WDSC team because
it's unsuitable to the task we're trying to make it do. I'm sure I
could use my scuba drysuit to carry gravel if I worked at it some. Now,
I might express intense curiosity as to _why_ offline development was
important enough to invent iSP, but that's another thread entirely, and
unproductive since we have what we have.
--buck
midrange.com
