Branching

brian.merzbrian.merz Posts: 55
Hello,

We are starting to look into branching our software into several different branches (dev/stable/release).

How does sql source control handle branching? Do I need to create one database container for each branch?

Thank you,
--Brian

Comments

  • Hi Brian,

    Thanks for your post. SQL Source Control will link a single DB up to a single branch. You can't have multiple branches working against the same linked DB as you cannot have multiple versions of an object in a single DB.

    I suspect that you process you would want to follow would be to link up the development DB to the development branch and then use SQL Compare or some other method to compare and synch from the dev branch to stable and then stable to release.

    HTH

    Pete
    Peter Peart
    Red Gate Software Ltd
    +44 (0)870 160 0037 ext. 8569
    1 866 RED GATE ext. 8569
  • It seems to me that there is a combination of SQL Source Control 2 and subVersion (say TortoiseSVN) that could be used to achieve the branching and merging. Has anyone put together an SOP on how to do that?
    Carla Hepker
    Documentation: A Shaft of Light into a Coded World
  • We place the trunk databases on the default sql instance in most cases. Our build machine uses the following instances for building each branch: sqlserver\trunk
    sqlserver\retro
    sqlserver\lab

    Each instance has the databases linked to different branches of the code in TFS/SVN, etc.

    This works. It would be helpful if there was some automation to 'move' the db's from trunk to retro. Currently we have to unlink all the databases and remove in the trunk instance and then create new blank databases and link in the retro instance.
  • I am curious as to why you have to remove the trunk instance and create a new blank database. Is it not possible to just merge from retro to trunk (or which ever way you are going)?
    Carla Hepker
    Documentation: A Shaft of Light into a Coded World
  • I also am having difficulties identifying the best practices for branching/merging with SQL Source Control in TFS. I suspect it differs from the best practices for creating and working with code branches. Currently, we have 3 database environments: development, staging, and production. Mimicking the best practice that we use for version controlling our code files, I created a main folder in TFS and linked it to our staging database. I then created a development branch from within TFS off of the main (staging) branch. I then attempted to link the development version in TFS to our development database in SSMS using SQL Source Control. However, I got the error that "The path must be an empty folder." How then does SQL Source Control support branching/merging? Does it actually support branching/merging through TFS, and if so, how would branching/merging be accomplished? Do you have any white papers on this? Any help here would be greatly appreciated.
  • Never mind. I figured out how to do this. I don't know why it was giving me this error before. After closing out of SSMS and then restarting it, I was able to link to my branched database.
Sign In or Register to comment.