Re: Subversion and RPG source change management

Thanks Arco. I posted by query to Aaron because at one time I think he was working on a project that used SVN to manage RPG code. You can find that reference here:

http://www.mowyourlawn.com/SystemiSVN.html

I'd be curious to see how it works but I haven't had the chance to try it out. Is this what you are using to manage your RPG code with SVN?

Pete


On 5/13/2010 10:33 AM, Arco Simonse wrote:

A few years ago I started to use SVN. After being out of RPG for a while, I
came back on it in the midst of 2009 and then started again to use the SVN /
RPG combination. Although I like SVN very much and I'm using SVN myself for
RPG source I would not advise it. You have to be very very consequent with
your source synchronization with the i, and it is a lot of work to keep the
file/member structure organized in SVN.

There are a few points that makes it difficult to work together with i
sources.

1. At the very first you have to completely change your mindset. If you use
SVN for your source, then your source master lives in the SVN repository.
You do not have your master source libs on the i, but in the SVN repository.
I have seen that this is very difficult to remember for RPG programmers. But
it is necessary to follow this rule, or else your SVN implementation will
not work.

2. SVN is oriented for use with flat files, and SVN knows nothing about the
i's library structure. So there is no way that SVN will recognize that some
source member on your i has changed. Only solution for that would be if
someone writes programs that can read and write to an SVN administrative
directory. But that does not exist, so you have to work around that. If we
could compile our RPG/CL/C source from the IFS (which is not completely
implemented yet) that would open many more doors, because you can then have
your working copy on the IFS and SVN can deal with the IFS.

3. For my own situation as alternative I have decided to use iProjects in
RDP to maintain my working copies from SVN. This works but gives many side
effects that you have to deal with. An iProject splits the original source
member in an RPGLE source text file and the information about the source is
put in an xml file, which lives in a separate folder in your project. This
is a nightmare to maintain when you want to move files between SVN branches.

4. SVN (and most other SCM's) is folder oriented. This means that when you
want to checkout a few sources from the repository, you'll get the whole
tree. So if you want to create an iProject working copy to edit 10 sources
from QRPGLESRC, you will get all lets say 1000 sourcemembers. Yes, there are
ways to work around that, but it's a lot of extra work.

The main reason I have continued to use SVN / RPG until now, is that as a
one programmer shop I can't afford a real SCM package. And for versioning
your sources it works very well. You can work with every source version you
want (provided you have committed as much as needed). But I don't see a
future for SVN with sources that are in the library system, unless there's
some software written to manage an i-side SVN administrative directory.

Best regards,
Arco Simonse

--