Re: Subversion and RPG source change

It is a big hurdle that there are several ways of i source editing, but
I think that an SVN client for i should support them all, even the "klunky"
ones. By the way, I can imagine there could be some dispute about how klunky
SEU is with regard to modern IDE tooling, but that's another discussion ;-)

I agree that from an i point of view there needs to be some Master Copy
stored in an i library. But in my thought - and I believe that is also the
Subversion idea - this master copy should always be an SVN working copy,
which is checked out from the repository from a tagged release. Not every
repository revision should be synchronised immediately to this master copy.
Imagine that you have your Master Copy checked out just from a tagged
release, say you tagged it as version 1.24, which is for example at level of
revision number 1540. Another developer has also checked out a working copy
of the trunk to his own IDE, and has worked on some source code. When he
commits this code (maybe in two or three commits 1541,1542,1543) you don't
want to have this code immediately applied to your Master Copy. That would
break a good release management. Instead of doing so, you should look
carefully what the changes in these revisions are, and if it is okay then
for example you will tag revision 1543 as the new production release 1.25.
That is much safer and more conform the Subversion philosophy than let
everybody digging around in your master copy.

So, from an SVN point of view every developer should work in his own working
copy (i.e. development library) and commit back to the repository from where
you can tag releases that you want to be checked out as your Master Copy.
Best regards,
-Arco
2010/5/22 Richard Schoen <richard@xxxxxxxxxxxxxxx>

In my thought process the master copies will always technically be in
SVN because you would be committing changes on a regular basis.

Another benefit of using source files as the master is that the
edit/compile/build process would still feel natural to an RDI or SEU
user. I have a hard time picturing check out to PC, edit with RDI,
save to PC, commit, check out to source file, build. Too many steps
unless you can describe a shorter process.

Developers would have access to the SVN options in RSE because you can
create user actions which would trigger CL commands for source
commitment. I would not use iSeries projects because that mechanism is
klunky. Furthermore users would still have to ability to use SVN and
Tortoise if desired to check out individual members to the PC as well.

On the IFS comment I have chosen to write headers to the source members
when first committed or the developer can pre-add them to each source
member. The header has 3 keywords @@MEMBER, @@TYPE and @@TEXT as header
keywords. This will allow source type and text to be automatically
rebuilt on a get or refresh of the source members from a repo. I don't
want to tie this to an SVN property because it could get klunky. Better
to recreate the source member, get the keywords and change source member
properties on a get or checkout.

My focus is to allow the source to be edited and maintained in either
RDI or SEU because we use both and most real world shops do as well.

SVN is a source version archive. That's its main purpose and what we
plan to use it for :-)

Queue David for the Change Management conversation..........

Actually I do want to look into the Rational Team Concert offering as
well. Apparently V2.0 is a little more compelling, however I wouldn't
relish moving all my SVN repositories to it.