I'm working on migrating my company from VSS to SVN for SVM. We develop tools for use by our business that live within a central web application. Right now our setup is as follows:
The Java developers develop and test locally, and once complete, check their files into VSS. Their local code points to a stage SQL instance. Once or twice a day, one of the developers gets all files from VSS, runs a build script to generate a WAR file, and copies the WAR file to one of our two common testing environments, dev and stage. The business then tests changes for their project in the appropriate environment. When it comes time for a production update, some of the changes that were checked in for testing on dev or stage aren't approved for production, so developers have to go and roll back the changes, so that the state of VSS can be built as a production build. Often developers lose track of what files they've changed and changes slip into prod that shouldn't have. Our SQL developers keep copies of stored procs in .sql files that are checked into a directory on VSS, and when they must modify one, they check it out, make the changes, update the stage SQL server, and at the time of a production update, update the prod SQL and check the file into VSS. Again, sometimes SP updates are missed and prod breaks.
My vision for SVN is as follows:
The root of the repo will have the standard trunk, branches, tags structure. Under the trunk there will be two folders, src (for java files) and db (for sql files) Developers create a branch for each changeset that they make. Be it a project, a support case, or some other change, each logical changest gets its own branch. Java and SQL developers will both work on the same branch for the same project, so that all changes for a project exist in one location. Once local development is done and its time to test by the business, they merge their branch into the dev branch, which is build every few hours by a script and places in our dev environment. Once the business has approved a change for production, the developer merges the branch into the trunk, which is built twice a day and put into our stage environment. At a prod update, the trunk is just built and copied to the prod server, and the SQL developers report on all .sql files changed since the last tag, and update those files to the prod SQL server. This way, there is no need to roll back changes for a production build, because only prod-ready changes are merged into the trunk. It also gives us the ability to constantly monitor the state of the stage code, making sure that there aren't any weird dependency issues with some changes getting promoted and some not.
Overall I feel like I have this down, but I fear that I'm missing something. I have extensive experience in git, but none in SVN (I tried to convince them to use git to no avail). Thoughts/suggestions?