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
