SVN for DB Objects? Need help with Setup!

  • My company has decided to start using SVN for source control of database objects. We have been having discussions regarding how to set up the folders that makes sense for a large IT shop.

    Questions are:

    * How do you handle keeping a view of what is currently in Production? Does the Trunk have production level objects only? Do the developers have access to the Trunk?

    * How do you allow multiple projects to be developed concurrently?

    * At what point do you merge your objects into the main development line (if they are branched off)? Who performs the merge?

    Any input will be valuable if you currently use SVN today with database objects. Thanks for your help!!!


    Todd

  • Have you checked the subversion help material? This will give you a basic idea

    http://svnbook.red-bean.com/en/1.7/svn-book.html

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉

  • Yes, SVN documentation has been reviewed. The largest issue for using SVN with database objects seems to be the inability to identify easily which objects have changed from one release to another. This concept is critical because we don't want to deploy 1500 stored procedures when only 3 are changing as part of the release! Branching seems to be the way to go, but some members of my team are concerned about the amount of merging that would take place, as well as when the Merge should be performed as part of the process. For example, it is ideal to have a merge of a branch into the main trunk prior to the rollout going to production, so code can be corrected. However, this seems to violate the rule of having production code only in the Trunk. If you have worked with SVN at all, please describe how your environment works. This will help my team to identify the best way we can use SVN. Thanks for your help!


    Todd

  • Red-Gate's SQL Source Control[/url] works with SVN, and it sounds like it will do what you're asking.

    Wayne
    Microsoft Certified Master: SQL Server 2008
    Author - SQL Server T-SQL Recipes


    If you can't explain to another person how the code that you're copying from the internet works, then DON'T USE IT on a production system! After all, you will be the one supporting it!
    Links:
    For better assistance in answering your questions
    Performance Problems
    Common date/time routines
    Understanding and Using APPLY Part 1 & Part 2

  • I never merged w/ DB objects.

    The Red Gate tool can help (disclosure: I work for RG), but it doesn't necessarily do all this. It's just an interface to the tool.

    The way I always did it was to assume the main trunk is always in progress. It tracks the state of the object history as it evolves. When you change an object for a release, branch it for that release, but leave it as linked. That way you can look at the branch and see the state of the object for release, but changes you make there are mirrored in the main trunk (or vice versa).

    When you go to prod (not QA), break the branch to a separate release. That gives you a known state for the release.

    Lastly, stick DB stuff separate from your app code (separate repository/project). Name the releases (branches) so you can track them from one side to the other.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply