Re: Subversion and RPG source change management

No, I tried Aaron's iSVN after he published the article and concluded that
-although it is a nice project- it is not what is needed to implement an SVN
solution.
How I circumvent the library limitations is that I imported all mij sources
in a mega iProject in RDP, and then imported that project to SVN via the
Subclipse plugin.
Regards,
-Arco

--
2010/5/13 Pete Helgren <Pete@xxxxxxxxxx>

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

--

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.