Branching

[brian.merz]

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

[peter.peart]

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

[cehepker]

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

[ccollins]

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.

[cehepker]

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

[mryhmln]

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.

[mryhmln]

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.