× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks for the feedback.

1.) Since we and most other shops have Windows Servers as well as
requisite backup software such as Veritas in place, backing up source
repositories for iSeries and non-iSeries source is a single step and is
already being done. The two backup locations scenario is really not a
big deal as long as you understand the platforms and implications.

2.) In my opinion OIR info is not as important for our product builds
because we ALWAYS do a full product rebuild. Our largest library is less
than 200mb of compiled objects. Quite honestly maybe I'm unusual but I
rarely look at object build information unless I want to see when it was
built to compare to what's in our product build library. Maybe I've been
infected by 15 years of PC development :-)

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: 5
date: Fri, 28 May 2010 09:53:16 -0400
from: "Mark S. Waterbury" <mark.s.waterbury@xxxxxxx>
subject: Re: Subversion and RPG source change managemen

Hi, Richard:

All good points. Please see my embedded remarks below.

All the best,
Mark S. Waterbury

On 5/28/2010 9:04 AM, Richard Schoen wrote:
Just a couple of comments that may or may not play into your efforts:

1.) Personally we have abandoned the Softlanding SVN server port and
running SVN natively on the i. Speed is just not good enough for our
environment. The AIX one could be better but since we've already moved
our server to Windows, no reason to look back.

From a "disaster recovery" point of view, your company will now have
two possible "points of failure" -- your System i machine is the first
one, and the other is the Windows Server where you are running
SubVersion hosting your SVN repository(s). Are the disks on that
Windows server all mirrored or RAID-protected? So, instead of just
simply running your nightly and weekly back-ups on i5/OS, you must also
ensure that your SubVersion repositories are also backed-up. And, how
will you ensure that those back-ups are "in sync" with each other? At
least, with a SVN host running on i5/OS, even under PASE, when you run
your full system back-ups (nightly and/or weekly), and include all the
IFS directories, you will have backed up "everything" including your now

precious SVN repositories, since this is now the "master" copy of all of

your source code for your products. If you were to lose any of that
stuff, as an ISV, this could cause serious harm (incurred costs, etc.)
to your business.
...(snip)...

This may fly in the face of some of the comments I've read here in
regards to preserving line numbers and dates and object info, but from
a
software vendor perspective it should work nicely to manage all of our
source projects using SVN. We are typically rebuilding our libraries
for
each new release anyway so the only time the object info really
matters
is when we build the product libraries.

I do not consider it a "big deal" or worry about the date stamps in each

source line. I am more concerned with the source file, library and
member name and source last changed date/time stamps reflected in the
OIR information of objects created from source, including: *PGMs,
*MODULEs, *SRVPGMs (for binder source), *FILEs, *CLDs, *CMDs, *PNLGRPs,
*QMFORMs, *QMQRYs, and *TBLs.
More food for thought :-)

Regards,
Richard Schoen
...(snip)...





As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.