Seems to me that this discussion is starting to move off topic for this
list. Maybe David would be willing to give us our own list, or maybe we
want to move this discussion to a SourceForge project.
There are at least two uses for branches. One to allow for forks in the
code base that are not intended to be merged with the trunk, but also to
allow for multiple parallel projects to be worked on. These can then be
merged back into the trunk as they are completed so that you don't have to
do your projects in series. This allows you to do break fix work in the
trunk and tag it to put it into production without having to distribute
partially completed programs. Otherwise your tag isn't really what is or
was in production at any given time. This is a key feature for any shop
where you could have more than one person working in a given application
(SVN project).
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/25/2010 12:15 PM
Subject: Re: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Sorry, it's taking time for me to get up to speed on this. I'm
alternating between reading this discussion and a Subversion tutorial, to
better understand terms like "branch", "tag", "trunk", and "property".
As a software company, we might use a branch to separate custom code for
specific customers. We'd try to keep that to a minimum, however. And we
wouldn't intend to merge that back into product mainline code, otherwise,
we'd probably add it to mainline source files to begin with, as a separate
source member.
So, as we consider the requirements of an IBM i SVN client, my inclination
would be to leave "branching" outside the scope; at least initially. Some
might use a PC based product to merge branches, then later synchronize
them with appropriate IBM i libraries, manually. Branches might be
treated as an exception to the rule. Instead, I'd scope the IBM i client
to focus on keeping library source files in sync with corresponding
directories in repository trunks.
Subversion properties seem like an ideal facility for keeping meta data
for source members, such as member descriptions. That would be a good way
to update member descriptions on separate working copies, on separate
servers, if that need were to arise.
We'd want to use tags for major cut-off releases. We wouldn't intend
change cut-off's. Again, we wouldn't intend to merge cut-off releases
with future development. Or, that would be an exception, to say the
least.
I'm okay with handling exceptions, perhaps using a PC based client, rather
than an IBM i based client, if push comes to shove.
- Nathan.
----- Original Message ----
From: Arco Simonse <arco400@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Mon, May 24, 2010 5:45:17 PM
Subject: Re: Subversion and RPG source change management
Until now we have only talked about working on the trunk, that is working
on
the mainline of development. There is another instrument of SVN that comes
in when we are talking about how to work with more developers. Branches. I
have hesitated for a while to bring this in to the discussion, because
working with branches can become fairly complex. But I think it has to be
mentioned.
When everything is done on the trunk only this flow is possible (but not
recommended from SVN view):
For production:
Repository <--> IFS Project dir <--> Project Libraries (The so called
Master Copy)
For individual development:
Repository <--> IFS Home dir of developer <--> Developers Libraries
Individual developers check in their changes, and when they are release
ready, the Master Copy is checked out and is ready for compile.
But what if one developer has a much longer project to do than another
developer? Do you want to keep them back from committing partial changes
to
the repository? Probably not, (if yes, review the concept of SVN) you want
to keep track of the development changes. But if developer A is ready and
developer B is still working you cannot create a release tag because the
trunk is broken at the partial changes of programmer B.
That's what branches are for. You can do parallel development on some code
parts branched from the trunk. You can even keep your branchecode updated
with changes that are done on the trunk. And when you are ready with
development, you can SVN let reintegrate (merge) your code into the trunk.
For production:
Repository <--> TAG release x.y in IFS Project dir <--> Production
Libraries (Production Master Copy)
For development general:
Repository <--> TRUNK in IFS Project dir <--> Development Libraries
(Development Master Copy)
For individual development:
Repository <--> BRANCH in IFS Home dir of developer <--> Developers
Libraries
Reintegrating branches can sometimes bring some complexity, and is best
done
in a GUI. The Subclipse plugin has excellent tools for this, for the
commandline there will be some difficulties to integrate in PDM I guess.
After all, even if branches are left out of the discussion, there will
also
be needed a mechanism that monitors if there are conflicting
differences between sources (this will happen on the IFS) when you are
synchronizing and/or updating the Master Copy which is actually a working
copy.
Best regards,
-Arco
midrange.com
