There's a bunch of stuff mixed up here and it is confusing everyone.
Subversion is version source control. Not change management. In general,
you don't "promote" to a collective location or path or branch or tag
within SVN. You commit your changes. At some point you decide what
version is distributable after building from a working copy. Any working
copy can be switched or updated at any point to any version or branch.
Each developer does his work in his working copy. You do not need a
branch. Each developer can go in different directions with his working
copy. Branches are usually only used for specific customizations that
will never become part of the trunk.
Each developer might have several working copies of the same project
going.
A working copy can be switched to another version (or branch or tag).
The SVN client MUST maintain an unalterable copy of the working as it
was at the time the working copy was made (co or update). The hidden
file you see in your working copy directory is this unalterable copy.
Keeping this "thing" is what is going to involve the IFS somehow unless
you want to keep it in a user space or some other protected object.
Without this "thing" you can't do a commit back to SVN.
In the context that has been used here, the source files in a library
are the working copy. The library itself is probably the checkout
directory. The files are directories within the checkout directory and
the mbr's are the svn files. When you create the working copy with the
checkout (co) command, SVN populates the members with source from the
repository at the revision specified. An update will merge the revision
from the repository as given in the command with the current contents of
the source files in the library. A commit will add a new revision to the
repository at which point the library may be deleted or it may continue
to be a working copy at the new revision.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: Tuesday, May 25, 2010 2:54 PM
To: Midrange Systems Technical Discussion
Subject: Re: Subversion and RPG source change management
The more I get into the Subversion tutorial, the more I see of value. I
personally wouldn't want to rewrite it. I'd prefer to run it under
PASE. But if that's not possible, I may break down and get a Linux
host. I'm kind of counting on Arco or an AIX expert to come up with
installation instructions for PASE ;-)
We're supporting multiple software products (student, finance, community
collaboration, etc.). Most of our products have two or more libraries;
at least one for runnable objects (*pgm, *srvpgm, *cmd), and at least
one for data objects (*file, *dtaara, *etc). Each product may have
different release levels, and may not be dependent on another product.
I envision separate SVN repositories for each. For example:
/svn/product/library/trunk/file/member.type
/svn/product/library/tag(release)/file/member.type
Where there may be multiple libraries per product, multiple files per
library, and multiple members per file; which is essentially comparable
to the traditional IBM i library file system. The main difference would
be having a directory structure that includes release levels (trunk &
tag), which fits right in with Subversion.
We'd need CL commands for check-in and check-out, because we use PDM.
But the idea of having RDP user defined options that map to commands,
would be appealing too.
-Nathan.
----- Original Message ----
From: Mark Murphy/STAR BASE Consulting Inc. <mmurphy@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Tue, May 25, 2010 1:03:38 PM
Subject: Re: Subversion and RPG source change management
This could be a good way to do it due to the fact that multiple
programmers would be working on the source on the i. At a recent
client, they have 4 environments set up in their CMS. Production, QA,
Integration, and Development. For the application I was working on,
each developer has their own development library, and them moving up to
the Integration environment is where the rest of the team can see the
changes I made. In my mind, this is where SVN comes in. On a PC
development environment, where there is only one developer per PC,
checking changes in to SVN is where my changes are made available to the
rest of the team. So I can envision an environment on the i where a
team has a "project library", and each developer has his own library,
and the process that moves things up to the "project library" also
commits to subversion.
If we were to write a subversion client for PDM, then the IFS portion of
the flow would not be necessary.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
--
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
