My thought is that svn update or checkout would fill the members through
the symlinks at the directory(file) level and vice versa for commit.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Murphy/STAR
BASE Consulting Inc.
Sent: Wednesday, May 26, 2010 8:21 AM
To: Midrange Systems Technical Discussion
Subject: RE: Subversion and RPG source change management
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.
midrange.com
