title: SubVersion (SVN) plan for huge # of database objects
body: <p>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.</p>
  
  <p><strong>Info:</strong></p>
  
  <ul>
  <li>There are over 1000 database (SQL) objects</li>
  <li>These objects are and can be separated by database/server.</li>
  <li>Objects are updated by a development but are deployed into production via the DBA group.</li>
  <li>We use Tortoise SVN primarily and would like to use it for any solution.</li>
  </ul>
  
  <p><strong>Scenario:</strong></p>
  
  <ul>
  <li>Change is made that results in 2 SQL objects being updated.  These 2 objects need to be deployed into production.</li>
  </ul>
  
  <p><strong>Concerns:</strong></p>
  
  <ul>
  <li>We don't want the development team or the DBA group having to check out a branch of 1000+ objects.</li>
  <li>We don't want the DBA group struggling to determine which files have changed.</li>
  </ul>
  
  <p><strong>Questions:</strong></p>
  
  <ul>
  <li>What is the best approach for setting up the branches for a SVN project of this size?  </li>
  <li>Is there an easy way for the deployment group to pull just the objects that have been changed?</li>
  </ul>