We are currenting using SVN for out .NET and Java objects and now we are looking at moving our RDBMS objects to SVN as well.
Info:
- There are over 1000 database (SQL) objects
- These objects are and can be separated by database/server.
- Objects are updated by a development but are deployed into production via the DBA group.
- We use Tortoise SVN primarily and would like to use it for any solution.
Scenario:
- Change is made that results in 2 SQL objects being updated. These 2 objects need to be deployed into production.
Concerns:
- We don’t want the development team or the DBA group having to check out a branch of 1000+ objects.
- We don’t want the DBA group struggling to determine which files have changed.
Questions:
- What is the best approach for setting up the branches for a SVN project of this size?
- Is there an easy way for the deployment group to pull just the objects that have been changed?
The same approach that the DBA group is used to, database / server.
Yes, but it requires some work up front. Put each and every SQL object in it’s own directory. Since Subversion checks out directories, your DBA group can check out individual SQL objects by their directories.
I used a Windows batch file to do something similar. The batch file used a DOS command to create a directory for each file in the master directory. In my case, I created a J1XXXXX directory for each and every J1XXXXX.cbl file in a master Cobol directory.
Someone can look at the Subversion logs if there’s a question about which files have been changed. A report can be created from the Subversion logs if the DBA group uses a unique identifier to identify their Subversion log records (Author, perhaps?).