SQL Source Control Creates a separate TFS "Workspace" for each Database
joshmiller
Posts: 1 New member
Hello,
I recently implemented SQL Source Control across 35 different databases in our environment. It seems to be working correctly within SSMS (i.e. I see the 'green' databases, and checking in/out works great). We use Visual Studio Online, and generally, select TFS as the method for storage of our source control (vs git).
My process for adding each of the databases have been to right click on the database in SSMS, then select "Link Database to Source Control". Then I select "Link to my Source control system (TFS). Then "Choose your Source Control System = Team Foundation Server (TFS). Once at the "enter your source control locations", I create a new folder in our source control environment for the files to live in. I think 'link' the database and done.
That seems fine, however....
I recently noticed that when using Visual Studio to access my other TFS projects (i.e. source control for c# projects), that I have a large number of "workspaces" (I would wager somewhere in the neighborhood of 35).
The original workspace that I was using looks like it got named to "SQL Source Control (guid)", and I am not sure how best to work with the local workspace now.
1 - Is it normal to have a separate 'workspace' for each of my databases?
2 - when you commit your first SQL Source Control project to TFS, does it rename any existing worspaces? (or clone them or anything?)
3 - I want to follow best practices for working with these many workspaces. I don't mind having a bunch of them around, if that enables the software to work. I just need to know how to work with my other worskpaces in this now shared space.
I am happy to screenshare (I have https://join.me/joshmiller that I can spin up at any time.)
I would appreciate an expert opinion on this.
Thanks,
Josh Miller
I recently implemented SQL Source Control across 35 different databases in our environment. It seems to be working correctly within SSMS (i.e. I see the 'green' databases, and checking in/out works great). We use Visual Studio Online, and generally, select TFS as the method for storage of our source control (vs git).
My process for adding each of the databases have been to right click on the database in SSMS, then select "Link Database to Source Control". Then I select "Link to my Source control system (TFS). Then "Choose your Source Control System = Team Foundation Server (TFS). Once at the "enter your source control locations", I create a new folder in our source control environment for the files to live in. I think 'link' the database and done.
That seems fine, however....
I recently noticed that when using Visual Studio to access my other TFS projects (i.e. source control for c# projects), that I have a large number of "workspaces" (I would wager somewhere in the neighborhood of 35).
The original workspace that I was using looks like it got named to "SQL Source Control (guid)", and I am not sure how best to work with the local workspace now.
1 - Is it normal to have a separate 'workspace' for each of my databases?
2 - when you commit your first SQL Source Control project to TFS, does it rename any existing worspaces? (or clone them or anything?)
3 - I want to follow best practices for working with these many workspaces. I don't mind having a bunch of them around, if that enables the software to work. I just need to know how to work with my other worskpaces in this now shared space.
I am happy to screenshare (I have https://join.me/joshmiller that I can spin up at any time.)
I would appreciate an expert opinion on this.
Thanks,
Josh Miller
Tagged:
Comments
Yes, SQL Source Control creates 2 workspaces for each DB (mirroring the Working Base and Transients folder on your system: http://documentation.red-gate.com/display/SOC5/How+SQL+Source+Control+works+behind+the+scenes).
SQL Source Control creates its own workspaces, it will not rename any of your existing workspaces.
The application will manage these workspaces, you shouldn't change any settings or use them (they should only be accessed by the process).
Those workspaces will be deleted automatically when you unlink a DB from Source Control.
I hope this helps,
Thank you,
Product Support Engineer
Redgate Software Ltd
Please see our Help Center for detailed guides on how to use our tools