Recommended setup for Red-Gate SQL Source Control

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace, andy.campbell.smith

Recommended setup for Red-Gate SQL Source Control

Postby mjharper » Mon May 13, 2013 3:58 pm

I have my databases in TFS using Red-Gates SQL Source Control – but I’m not convinced I’m using it in the best way.

My setup is that we have one “nearly” core database that gets replicated for each client. This core is probably 90% of the objects. There is then the 10% that are client specific. For example there may be a View that filters on different names for different clients, there is a user that is unique for each client database (but linked to a standard role).

At the moment I have each client database linked to the same TFS project (in dedicated model). If there is a bug found I fix it in one client database and check-in. Then I get latest for all of the other client databases. I have to be careful when getting latest not to get objects that are different for each client (there is a generic version of each object in TFS which I use initially, but once I’ve configured the database for the client I don’t want to overwrite the database version with the one from TFS). I also have to be careful when committing changes as I don’t want to overwrite the generic version with the client specific version.

I’m sure this kind of setup isn’t unique – how are other people handling this? Any advice is much appreciated. (I’ve posted this question on http://ask.sqlservercentral.com as well)
Matt
mjharper
 
Posts: 7
Joined: Tue Oct 27, 2009 12:35 pm

Postby james.billings » Wed May 15, 2013 5:42 pm

I see you've had one reply over on SSC- I couldn't tell from your original post if you do have just a subset of the database currently source controlled right now though?

One other option we came up with is to look at filters- you could add a filter to each customer database to effectively exclude all the customer-specific objects. You can read about filters here. This means you can safely get/commit objects and know they are just the shared ones (assuming you set it up correctly)

The downside of this of course, is setting up the filters requires some initial configuration (and possibly ongoing maintenance). Also, if there are dependencies between objects you're changing and the customer-specific ones, you may find that customer specific objects still get committed. You can turn off dependencies by editing the options

Hope that helps!
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.


Return to SQL Source Control 3

Who is online

Users browsing this forum: David Priddle and 0 guests