It would need to link all the way down to the member. We may be able to
do it without the IFS by having an additional source file name svn, and
keeping all the hidden members there. Once again that would involve
writing a native client for pdm.

I have the 1.4.0 source from softlanding. If we could get the 1.4.0 unix
source, and compare it, maybe we could devine the changes necessary to
build a native client.

Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx



From: "Dan Kimmel" <dkimmel@xxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 05/25/2010 06:54 PM
Subject: RE: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx



I'm wondering if symlinks in an IFS directory that is the working copy
directory would work where the symlinks are to source files in a
library.

Say the IFS (probably QOpenSys) directory was named workingCopy it would
contain the following symlinks

qrpglesrc = /qsys.lib/wclibrary.lib/qrpglesrc.file
qcllesrc = /qsys.lib/wclibrary.lib/qcllesrc.file
qclesrc = /qsys.lib/wclibrary.lib/qclesrc.file

Then the adapted svn client need only be an AIX SVN client with the
additional function to create the corresponding library on the checkout
command and create the files that correspond to all the subdirectories
within the path. It would have to check the directory structure during
the checkout and only allow checkout when compliant. update and switch
and commit would work without (much) additional change.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, May 25, 2010 5:29 PM
To: Midrange Systems Technical Discussion
Subject: Re: Subversion and RPG source change management

From: Dan Kimmel
There's a bunch of stuff mixed up here and it is confusing everyone.
Subversion is version source control. Not change management.

You and others have made that point before. And it's a good one. I've
made an effort to structure all my remarks in the context of using
Subversion ONLY for source code. I'm not trying to promote a discussion
about managing executable objects, which would obviously have broader
scope.

On the other hand, Subversion does support release levels (tags). You
can have release cut-offs, where complete copies of related directories
& files are made under release-level (tag) directories. That's about
the extent of my understanding of "change management".

You do not need a branch.

I agree with that. Subversion may support branches, but as I said
earlier, I personally would prefer not going there. I'd rather use a
graphical PC client for handling branches, if the need were to arise.
I'd rather not broaden the scope of an IBM i specific implementation.

In the context that has been used here, the source files in a library
are the working copy.

I understand the point. And I've been supporting that idea throughout
the discussion. But more recently, for clarity sake, we might need a
new term to distinguish our product libraries from their corresponding
IFS directories (which would be needed for syncing with Subversion
repositories).

I hope that my latest comments about checking source between our product
libraries, and individual programmer libraries, are not adding to the
confusion.

-Nathan.




--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.




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.