The .svn directories contain hidden subversion information, they do not
contain the working copies. Well, not technically. If you look in there,
the sources are stored twice on checkout. Once in the .svn directories,
and once in your working copy. Don't change what is in .svn if you don't
want to mess things up. SVN uses these copies to do comparisons to
determine if something has changed. We would need these in the IFS, but
may not need to store the working copies there if they are source files.
Binary documents would have to be stored in the IFS.
Mark Murphy
STAR BASE Consulting, Inc.
mmurphy@xxxxxxxxxxxxxxx
From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 05/25/2010 04:32 PM
Subject: Re: Subversion and RPG source change management
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Right. Among other things, the IFS portion would contain the .svn
subdirectory and the various hidden content therein. The Subversion
tutorial makes it sound like some SVN commands operate only on those
directories, which it defines as "working copies", perhaps without any
immediate interaction with the repository. Setting file properties, such
as "member name", seem to operate only on the local file system. Later,
the properties would be automatically submitted to the repository during a
"commit". Of course, we'd need something additional, and IBM i specific,
for keeping our product libraries in sync with "working copies (IFS
directories)", in addition to keeping working copies in sync with
repositories.
-Nathan.
----- Original Message ----
From: Richard Schoen <richard@xxxxxxxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Sent: Tue, May 25, 2010 1:18:23 PM
Subject: Re: Subversion and RPG source change management
Actually if you're going to use SVN at all, the IFS portion of the
equation is always needed because it is the middleman between the SVN
repository and source files for an application build.
If you were to use my concept of "source files as masters or what you
call a project library", there might be an SEU command to copy/check out
the source member to your library so you can work on it. Then when you
promote it back to the master source member it could get auto-committed
to SVN.
In our case we use a master library for each product.
Ex: SRCPRDNAM
If each developer could check out (make a copy of) the source member
from SRCPRDNAME to their DEVLIB and then promote it back to SRCPRDNAM
which would auto-commit the member that might be useful.
This same concept could work for RDI or SEU/PDM.
Not sure if that's what you were envisioning.
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
midrange.com
