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
