That's where I would only have three libraries.
It would be 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.
At least that is how I envisioned it.
I am not a heavy SVN/CVS user, I just like it as a source repository for
Java and being able to see what has changed and when.
Thoughts on my approach?
Aaron Bartell
http://mowyourlawn.com
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Adam Glauser
Sent: Wednesday, November 28, 2007 10:46 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Automate source code backup to SVN
Aaron, I'm curious as to your current source organization, because I
think it has some bearing on how you will want to set up your SVN
sync'ing scheme for future flexibility.
Do you have libraries something like this?
maincode - this the code to be backed up. Ideally it would always be
working code
develab - developer library where you would make and test your changes
develag - developer library where I would make and test my changes
...
develrp - developer library where Random Programmer would make and test
her changes
I think this is a common setup, and if you go the route you are planning
(auto-commit of /maincode/ at regular intervals) you might lose some
useful SVN functionality.
midrange.com
