TFS Integration Concerns
MartinU
Posts: 14 Bronze 1
Some things that I think are a bit disconnected between SSC and TFS working in a dedicated database environment.
1) When you modify an object on your dedicated dev database and SSC marks it as edited it does not actually check out the script or file in Source Control. In return, you cannot use the shelve feature of tfs if you wanted to because your files are not actually checked out anywhere.
2) When you modify an object on your dedicated dev database and the file (object) is different in source control it does not automatically load the latest version of that object.
I think the biggest problem I see here is SSC is storing the resulting script files directly to TFS server rather than checking out the files on the server, updating them locally and then committing them to Source Control when checked in.
1) When you modify an object on your dedicated dev database and SSC marks it as edited it does not actually check out the script or file in Source Control. In return, you cannot use the shelve feature of tfs if you wanted to because your files are not actually checked out anywhere.
2) When you modify an object on your dedicated dev database and the file (object) is different in source control it does not automatically load the latest version of that object.
I think the biggest problem I see here is SSC is storing the resulting script files directly to TFS server rather than checking out the files on the server, updating them locally and then committing them to Source Control when checked in.
Comments
We've had a fair number of requests, predominantly from TFS users, to support the check-out model of source control. The model that SQL Source Control has adopted is more akin to that of Subversion, where you modify objects without checking them out, and only upon commit are conflicts considered. The reason we chose this is not only because of its simplicity, but because unless we instrument dedicated databases with DDL triggers, there's no way we can prevent a user changing their database even if another user has taken a lock in TFS. What we hope to do in future is to provide more information on who is actively changing which object, so although we can't prevent users changing the 'same' objects at the same time, we can warn them when they start doing it.
Your suggestion to get the latest version of an object on edit is a nice option we could also add in future. Please suggest or vote for any ideas you have on our uservoice forum. http://redgate.uservoice.com/forums/390 ... ce-control
I hope my explanation makes sense. If not, let me know.
Thanks for the feedback,
David Atkinson
Product Manager
Red Gate
Product Manager
Redgate Software
However, if you plan to engage in 'connected development', where you modify a real development database linked to your source controlled database, you could still get into a situation whereby User A has checked out an object, and User B unknowingly modifies the same object on their connected database causing a conflict when they eventually try to push their changes down to the project and check them in. If this becomes an issue, we'll have to consider implementing the DDL-Trigger-based solution, or come up with another solution.
Out of interest, what would you like to see in pre/post-deployment scripts?
David
Product Manager
Redgate Software
1) Ability to execute static data scripts when synchronizing. Should be optional.
2) Ability to perform an actual merge when conflicts arise.
There may be other things but in regards to our teams and development process this is what we would have expected the VS DB projects to be where we can develop in VS or on our local and quickly and easily move things back and forth. The speed and the fact that it mimics how items are scripted from SSMS is ideal. Where things on a table level such as triggers are part of the table script and not a separate object in the solution somewhere is key as well.
I'm not sure what happens if you have more than one RG project in a solution. I guess the sync should only apply to the project, but I don't see why this couldn't also be an option at solution level if you were to have multiple RG projects under it. Please post these requests on the SQL Connect UserVoice site!
http://redgate.uservoice.com/forums/140 ... ilters/new
Regarding the merging, SQL Connect just leverages your current VS TFS integration, it should 'just work'.
David
Product Manager
Redgate Software
Could you do one last thing for me and point me to a resource or a quick write up of how SQL Connect and SQL Source Control work together?
I understand SQL Connect is still in beta but if we were to work on a long term plan with our current SQL Source Control 3 rollout, how and where does SQL Connect play into that plan.
I have been doing some testing with SQL Source Control 3 and the SQL Connect plugin and can kinda see where each one fits in but I am curious as the direction that Red Gate is going with SQL Connect.
If there is another method or location where these types of communications should occur please let me know.