RE: Automate source code backup to SVN -- MIDRANGE-L

The key determining factor for me on this point is if SVN recognizes
that a commit being done is for a file that hasn't changed. My hope
would be that it would simply disregard the commit for an unchanged
file. If that is true then an autocommit each night is a solid approach
to ensure code is backed up AND all changes are logged from the last 24
hours. No coding on the i5 would need to be done on determining which
source files had changed.

SVN will only commit changed source members.

Then if you ran an auto-commit of your working source each night it
might work.

However if the source members are in source files you would have to rip
them down to PC files before committing them.

Here's a possible process flow:
- Roll thru source files and look for changes.
- Extract changed source members to selected IFS folder.
- Commit all files in IFS folder and let SVN handle the determination
and committing of just the changed source members.

I don't think Mark released a command line version of the SVN command
line program caller so you might need to see if there's a PASE version
of the svn commit code.

Just some ideas :-)

Regards,
Richard Schoen
RJS Software Systems Inc.
"Get the information you need. Now!"
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 898-3038
Fax: (952) 898-1781
Toll Free: (888) RJSSOFT

-----Original Message-----
----------------------------------------------------------------------

message: 1
date: Thu, 29 Nov 2007 09:23:04 -0600
from: "Aaron Bartell" <albartell@xxxxxxxxx>
subject: RE: Automate source code backup to SVN

You may not want to autocommit all code each night into SVN.

I wonder if maybe just using WDSC to edit members and then using
Tortoise

to commit them would work.

All source members would have to make their way down to the PC. Right
now source only makes it down to the PC when you edit a specific member,
and even then it is loaded into a directory that has "temporary" written
all over it - can't rely on it IMO.

The other approach is obviously iSeries Projects, but those are simply
messy to work with (I have been using them on a project with a client as
a way to exchange source from one machine to the next and also used to
change manage it).

I think in the end it comes down to wanting EVERYTHING on the i5. That
way there is no additional setup needing to be done on each PC (i.e.
TortoiseSVN, etc) and the failure points are less. The more we keep it
on the server the less "maintenance" it needs on a per programmer basis.

If this is the case you could just store your files in the IFS as a
work

directory and commit to SVN from there even if SVN is on another server.

I am also very interested in this. Everytime I move forward with trying
to make it work I get caught up in something else. Is anybody using
this in a more than "playing around" capacity?

FYI: SoftLanding already tried to slip us a 12 month expiring access
code

after we renewed this year :-)

Ouch. Sounds like the buyout changed A LOT of things in the company -
too bad.

Aaron Bartell
http://mowyourlawn.com