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
2010/5/25 Nathan Andelin <nandelin@xxxxxxxxx>
I've just been reading a tutorial on Subversion which discusses the
relationship between repositories and local working copies; where local
working copies are normally project directories.
I envision project directories mapping directly to IBM i project libraries,
and using CPYFRMSTMF and CPYTOSTMF to keep project libraries in sync with
project directories, and other actions for subsequently keeping project
directories in sync with Subversion repositories, and visa versa.
I actually prefer the classification "project library", in order to
distinguish between "shared" project libraries and "individual" programmer
libraries. In many shops, individual programmers will "check out" source
from shared project libraries. Then after source changes are made and
tested, members are "checked in" to project libraries. The check-in event
would probably be a good time to commit changes to the project libraries,
back to the Subversion repository, too; where Subversion keeps track of
revision histories.
Flows might occur as follows:
Repository <==> Project Directories (IFS) <==> Project Libraries <==>
Programmer Libraries
So you might have one set of actions for individual programmers to check
source files, and another set of actions to keep project libraries in sync
with repositories.
-Nathan.
midrange.com
