I have watched this thread with interest.
SVN isn't a replacement for the SCM solutions ... but it does provide a
source code management solution when an individual/organization is budget
constrained.
While we use an SCM solution at work ... I still keep a SVN repository of
"owned" projects to easily manage and track source code changes.
I have used the elcipse (read rdi/rdp/zend studio)/svn integration option
for about 6 years. I think it comes down to cost, risk, effort, and reward
issues.
Including iProject into this mix solely for source code management is a bit
kludgy ... but I have found it worth the benefit. Like most developers ...
I want to easily track and manage source code changes ... svn is an good
open-source (read no cost) repository ... and iProject (worts and all) is
the "bridge" that makes it possible to use w/in RDP.
The piece that is missing is a "native" svn client that can be used from the
traditional pdm environment so all IBM I developers could utilize the same
repository. If I remember correctly, there was an attempt by Aaron Bartell
to create an "open-source" iSVN client to accomplish this. I don't think it
was ever completed due to lack of interest by the community.
-----Original Message-----
From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On
Behalf Of Richard Schoen
Sent: Friday, July 29, 2011 11:36 PM
To: wdsci-l@xxxxxxxxxxxx
Subject: Re: [WDSCI-L] Using RDP 8.0 i Projects
Well, IMO, that's just a kludge. You're taking a source control mechanism
that's not designed to work with IBM i and finding a way to wedge it in.<<
Well this is essentially IBM's pitch with RTC, so if it's a wedge then it's
their wedge.
Their pitch was to use IBM i projects to manage your development and use
their source control or SVN or whatever you want to manage your source.
Then use their IBM i packaging process which doesn't look too bad. (But
that's another topic)
(This whole pitch and wedge thing sounds golf-like. I miss golf. I
digress....)
If it's a kludge, then you're pretty much telling IBM that the RTC for i
integration sucks :-)
I think it's a workable option for those who are willing to step out of
their box and make a little paradigm shift, but don't want to or can't spend
a ton of cash.
This would work especially well for small IBM i development staffs or
vendors, unless they are stuck on SEU only.
True, but the development model isn't natural for IBM i.<<
It's not totally unnatural either. It's change. And if someone isn't using
RDP/RSE they probably won't ever see or use the i projects or SVN, thus it's
moot for those people anyway.
You're basically saying that IBM i developers can't change because it might
get too uncomfortable :-)
There's always SEU to fall back on and SEU would work in this scenario as
well if each user checks source out from a SVN repo to their own i project
assigned to their own library they have an SEU sandbox as well :-)
They would upload source, work on it, edit, compile, edit, compile, etc.
Make available offline to project and commit to SVN. Not ideal, but also
not that hard to remember.
It's a process just like STRSEU, F3, Save Changes Y STRSEU F3, Save Changes
Y................
PLUS you run the risk of two developers overwriting everyone each others
modifications ... since the IBM i project mode doesn't lock the source
member while it is being edited.>>
As an SVN user yourself you do understand the commit process with SVN,
correct ? Each user has a sandbox and when members are committed you get
conflict checking.
Again not perfect, but having used SVN the past 4 years it's pretty good.
Quite frankly, seeing the low community interest in the SVN client for i
that Aaron and I announced, I believe this is the next best option for
someone who wants to source/object code manage their IBM i projects with
SVN.
And no development required. Just hook it up to RDP 8.0 and start managing
your source and objects.
I for one am going to test the RDP/SVN process on one of our projects and
see what the holes are.
Might be fodder for an educational class at COMMON or a commercial offering.
Who knows................
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
-----Original Message-----
Install the SVN Team provider, right click on your i project, select
Team/Share Project/SVN and you're golden.
RDP 8.0 is hooked up to SVN and ready to roll. This could make
writing a specialized SVN client redundant and unnecessary.
Well, IMO, that's just a kludge. You're taking a source control mechanism
that's not designed to work with IBM i and finding a way to wedge it in.
I think you would be better off getting a host based SVN client working and
simply adding some RSE user defined options rigged up to do your check in &
check out functions. A subsequent implementation could contribute first
class actions to the RSE popup menu to invoke the checkout & checkin.
You can easily push and pull IBM i source members for compiling at
will as well as objects that you want to version control in SVN.
True, but the development model isn't natural for IBM i.
PLUS you run the risk of two developers overwriting everyone each others
modifications ... since the IBM i project mode doesn't lock the source
member while it is being edited.
Probably not as cool as MKS and others, but this could work nicely
for those who don't have the cash to buy a full blown
source/application management suite.
While our current plug-in is pretty seamless ... our initial implementation
used user defined options to invoke product commands.
If someone didn't want to install our plug-in, they could setup the original
implementation and it would work quite adequately.
david
midrange.com
