trunk has nothing to do with production. trunk holds all the revisions.
The svn update command will update from the latest in the trunk unless
you give a revision number. If you give a revision number, you'll get
the latest at that revision. Tags are a way of "remembering" the
revision number. All a tag does is associate a revision number with a
name. So you might have a tag called "Latest production release". You
could rebuild the latest production release from a working copy based on
that tag. When you decide you have a new version that can be released,
you update the tag with that revision number. There also may be a tag
named "Version 1.0" that is also tied to that revision number.
When you commit, you do not replace what is in trunk. You add a new
revision.
Any working copy can have the whole production code by doing an svn
update command referencing the "latest production release" tag.
-----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 9:56 AM
To: Midrange Systems Technical Discussion
Subject: RE: Subversion and RPG source change management
No you don't, and you don't need SVN to do source control, it just makes
things easier.
If I am developing in my working environment and do not commit to the
repository, how do you get my changes? You don't, I have to commit to
the repository at least daily if we are to work together on the same
module within an application. If I am not committing to a branch I must
be committing to the trunk. Say someone needs a fix, well now that the
trunk is not ready for production, you can't get there from here.
Unless I am missing something. It seems that you are thinking of a
single developer per project, and that you don't commit to the
repository until you are ready for production. That is too inflexible,
and wouldn't work well for most of the projects that I have been
involved in. Or we have our terminology garbled.
If there is more than one developer on the team, no working copy will
have the whole production code, and therefore the promote to production
cannot occur from any one until everyone has committed to somewhere, the
trunk, and one of the working copies has been updated to include
everything that is needed for the final production build. I tag that
first, from the trunk or a branch if it is really a different version,
then do the build from there.
Say I have 6 developers, 2 are working on invoicing, 2 are working on
item maintenance, and 1 is working on maintenance fixes. There may or
may not be any overlap between these project though they all involve the
same retail application. If they commit in the following order,
invoicing dev
#1 - version 51, item dev #1 - version 52, maintenance - version 53,
invoicing dev #2 - version 54, item dev #2 - version 55. Which version
holds just what is in production plus the invoicing changes?
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
From: "Dan Kimmel" <dkimmel@xxxxxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion"
<midrange-l@xxxxxxxxxxxx>
Date: 05/26/2010 10:23 AM
Subject: RE: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx
You do not need branches in SVN to support the envirnoment you describe.
Each of those developers works in his own working copy. When each is
ready, (s)he commits their changes. That doesn't affect the other
working copies. When the next developer commits, his changes are merged
in to the previous changes. There may be conflicts, but I've seldom seen
any and they are easy to resolve. The order the developers commit their
changes is immaterial.
You never "go into production" from trunk. You go into production from a
working copy build. That working copy can be made from any revision in
trunk; they are always there, not just the latest one.
Change management is not done from SVN. Change management is done by
choosing which revision can be used to produce a production quality
build.
-----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:15 AM
To: Midrange Systems Technical Discussion
Subject: RE: Subversion and RPG source change management
Here is why I believe that branches are necessary and desirable. Say
you have a large application, Subversion calls it a project, but in the
i world we call it an application such as a retail application. This
application may have multiple modules, and the group developing it may
have a half dozen developers or more. If the group is large enough,
there may be two or more projects going at one time, plus fix work. If
there are no branches, then only one developer can work on any given
project because only that developer has the appropriate working copy.
Or the projects and even the fix work must be done serially. Now in my
experience it is impossible to determine at the beginning of a group of
projects which will get put into first unless the projects have
dependencies between them. In fact it is impossible to state
emphatically whether any given project will be put into production at
all when it finally comes down to it. I am sure we all have had
projects reprioritized or cancelled mid stream. If all that work is
done in the trunk, then any commits done will go into production all at
once, ready or not. This could lead to a bad situation, or at a minimum
it could cause extra work trying to determine what pieces to add to the
tag, and what pieces to leave out.
To finish that thought, while I am working on a project it is critical,
unless I am the only developer working on that project, to perform
regular commits to allow the rest of my team that is on the project with
me to have visibility to my changes. If these changes are not yet
production ready, then they should not be committed to the trunk because
the trunk needs to be production ready at all times. Fixes are made and
committed there to be promoted immediately.
You cannot totally discount promotion to production because that is what
development is ultimately all about. While using SVN for source control
will not provide all the features of a change management system, it does
provide the foundation, and if that foundation cannot support proper
change management, then it will not be sufficient for source control in
a team environment. That last phrase 'in a team environment' is key
because in it's absence, dedicated source control tools are not really
necessary.
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 05:47 PM
Subject: RE: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx
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
