Unfortunately the Commit can fail if there are conflicts, and needs to be
watched. I don't think a late night commit with no user intervention will
be a good solution.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/28/2010 12:22 PM
Subject: Re: Subversion and RPG source change managemen
Sent by: midrange-l-bounces@xxxxxxxxxxxx
What a flurry of activity! I'm please to hear about Arco's success with
the running the AIX version. I'd like to try it on my server, but my PASE
qualifications are close to nil, so any instructions, pointers, or tips
would be most helpful. I could also use the Apache configuration to
support remote SVN clients.
Some of my thoughts about an IBM i SVN client were influenced by TAATOOLS:
http://taatool.com/document/L_srcctl.htm
Those are primarily command-line tools, written in CL, where most of the
source-control configuration, audit, and history data are stored in IBM i
tables.
I was also influenced by comments here, and from other sources, which
discussed a "distributed" approach to source control, which address
performance concerns. Checking source out & in, against the IBM i
library-file system performs exceptionally well. From there, all we'd
need to do is to synchronize those changes with a Subversion repository,
which could be performed asynchronously (in batch); perhaps at night.
My other reasons for using IBM i tables to store configuration, lock
state, and check-out/check-in/repository-resolution data, would be to make
it easier to query and report source-code change. I don't see that as
reinventing the wheel.
I'm not very qualified in RSE, or other Eclipse-based tools, but my
understanding is that RSE could evoke CL commands or programs to run
check-out & check-in procedures.
It appears that synchronizing IBM i library/file/members with a Subversion
could be handled by wrappers around the PASE SVN client. But I'm also
interested in the approach that Aaron Bartell took; using the Java-based
SVNKit.
-Nathan.
----- Original Message ----
From: Mark Murphy/STAR BASE Consulting Inc. <mmurphy@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>;
svnci-developer@xxxxxxxxxxxxxxxxxxxxx
Sent: Fri, May 28, 2010 9:19:13 AM
Subject: Re: Subversion and RPG source change managemen
That is an interesting point. I am wondering if what we really need is a
plugin or extension to RSE that hooks in to a PDM client, or if we would
do better extending the Subversion plugin for eclipse to support RSE.
I am cross posting this to svnci-developer@xxxxxxxxxxxxxxxxxxxx
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
From: Arco Simonse <arco400@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/28/2010 11:07 AM
Subject: Re: Subversion and RPG source change managemen
Sent by: midrange-l-bounces@xxxxxxxxxxxx
The current SVN plugins for Eclipse all do work with the principle of
checking out a working copy to a local Eclipse project. They do not
function
within RSE. I have no idea if that has a technical reason or what. However
I
would like it very much if RSE functionality could be eshtablised. I know
little of RPGNEXTGEN, but I assume it also works with RSE?
Would it would be developing in two different worlds? A native SVNci
client
would require wrappers around the PASE svn programs or maybe patches in
those programs themselves. I don't know if that would also help the
implementation/modification of an Eclipse client, I don't know about how
the
technique works that would be used to connect from Eclipse to the i.
Regards,
-Arco
2010/5/28 Mark Murphy/STAR BASE Consulting Inc. <mmurphy@xxxxxxxxxxxxxxx>
Actually there are several Eclipse plugins for SVN. I was thinking that
this would be more and enabler for PDM users.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
midrange.com
