× 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.



I strongly agree with this. SVN documentation calls this a working copy.
The master is in the repository, and is not maintained directly by
anything. This keeps it safe. Anyone can synchronize their working copy
with the repository to get the latest version of the software. Unlike
tools like Aldon, check-in does not remove a piece of source from the
working copy, so you an always work from where you are, and when ready
update the repository. What you would need is a custom option for PDM
that would compare the source in your working copy with the repository,
and then let you know what is out of date. That tool could also allow you
to update your working copy from the repository to get the most recent
updates from the repository.

This is really a different way of thinking about development from what we
are used to. With SVN you don't check out a program into your development
library, update it, and then check it back in (which removes it from your
development library). Instead, you have all the sources in a development
library, and the production source is in the repository. As folks work on
individual sources they check the in to the repository which updates the
version number for the source, and updates the data store in the
development library that tells the version number of each source along
with some other info about the source. When you are ready to move
something up to production, you check in the relevant source, and create a
tag. If you are working multiple releases concurrently, you may need to
use branches to keep each development effort separate until it is ready to
be merged into the trunk, and then moved into production.

If you look at a SVN client, you will notice hidden files in the
directories backed up by a SVN repository. The hidden stuff is in the
.svn directory. It tells key information about everything in the
directory with respect to SVN. Odds are we are going to have to do
something similar, but keep it in the IFS. We are going to have to build
a SVN client for green screen with hooks into PDM.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx



From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/24/2010 12:22 AM
Subject: Re: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx



It's true. We don't have any Linux or Windows servers; just IBM i. Our
web site is hosted under Linux, but out ISP controls that. So, I'd be
interested in a PASE option.

What you're calling a "master copy", I'd just call a "development
library". Technically, you could have multiple IBM i clients on separate
servers, where each is synchronizing with a single SVN repository. An
open source project might run that way. You could be collaborating on an
particular project, without enabling full access to your IBM i server;
just sharing a common code repository, for a specific project, where each
IBM i client may have a complete copy of the repository, and building an
application on separate machines.

We wouldn't think twice about PC clients having complete copies of SVN
repositories, but we somehow see an IBM i client differently, perhaps
because it's normally hosting multiple developers itself, concurrently.
But of course, the development library would continue to be used to manage
and build an application.

Regarding, streamlining the client interface, reducing the number of
actions it takes to effectively use SVN, makes sense to me.

I appreciated Mark's comments about what you might give up, by using
Subversion. People need to take them into account, and perhaps look for
ways to mitigate the downsides.

-Nathan.




----- Original Message ----
From: Richard Schoen <richard@xxxxxxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Sun, May 23, 2010 12:41:20 PM
Subject: Re: Subversion and RPG source change management

My point being: Is the iSeries really your only server box in today's
world ?

If you really want to run the SVN Server on iSeries, I believe you can
still use the Softlanding port or if the AIX one works you could use
that as well.

When I say "master copy" I mean the version of code that is always most
current and ready for editing. This is not an SVN term. Just a general
concept of the source files most always being the place to go for
initiating editing. As I've described previously, in my world you will
ALWAYS still be able to check-out source members from SVN and commit
changes from ANY SVN client. Your source files and SVN would be kept
in-sync via regular updates and commits.

I think you may be missing the concept that SVN would still ALWAYS be
handling the versioning, tracking tags, branches, etc. even if the
source files are still used as masters.

In my opinion the only thing that IS lacking is a native iSeries SVN
client. I believe that's pretty much what I've been talking about all
along :-)

Ultimately it doesn't matter where the SVN repository lives. The issue
is how to make it easy for iSeries developers (RDI or SEU) to naturally
tie into SVN. If it's more than a few clicks, then it's cumbersome.

I'll use the same comment I tell customers: "Our job is to reduce the
number of mouse clicks it takes you to do your daily work. If we
haven't done that, then we haven't helped you much :-)"

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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.