Re: Automate source code backup to SVN

Hello,
How I am doing things now:
I have SVN installed on windows and TortoiseSVN for all developers. We are
developing our programs in gVIM as it is a far better editor than SEU (hell
even Notepad is :) ). Than we use (from gVIM but can also from command line)
a simple command to put the sources on the iSeries using FTP in our own
library. When we are happy with the source we commit it in Windows. At
commit we have an automated process that copies the sources into the main
developers library (under user's library in user list) and compiles it
depending on the extension (RPGLE, PF, DSPF, etc).

So the process is quite automated and we are very happy with it - it works a
lot faster, you can store your sources everywhere and you can even use
google code (http://code.google.com) with it


Best regards,
Mihai

http://rpgCRUD.ro
<http://rpgcrud.ro>tzighi@xxxxxxxxx



On 11/29/07, Adam Glauser <adamglauser@xxxxxxxxxxxx> wrote:

Aaron Bartell wrote:

I would only have three libraries [...] PROD, TEST, DEV.

A developer would make all their changes in the DEV library (not their

own

library). Each time they saved the member a SVN comitt would happen.
When they were done with their coding they would move the member to TEST
at which point another trigger would happen that would submit that

source

to another
SVN folder. The same would happen when promoting to PROD.

Well, that seems like a pretty reasonable way to get started. It buys you
the version history functionality that seems to be your main goal. I'd
suggest that committing every single save to the DEV library might be a
bit
excessive, but that just me. I haven't used SVN enough yet to know
whether
a really large number of commits could get unwieldy in practice.

The nice thing about your approach is that if you want to get some of the
other benefits of using SVN (like branching and tagging), it should be
fairly easy to modify or augment the process. For example, as your team
gets more comfortable with SVN, you might each want your own working
directories instead of a single working directory. This would allow two
people to collaborate on the same parts of the code at the same time more
easily, or try out different directions of development simultaneously.

Hope this is of some use,
Adam
--
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.