Thanks a lot for the question Surm!
The answer really depends on which Source Control model you have adopted. Sql Source Control supports a. Dedicated model b. Shared model. In a. each user is connected to the source control repository with their own local version of the database and its objects . In b. each user is making changes to the same database. In the dedicated model connected to Tfs the problem you describe would typically be overcome by using TFS object locking which is partly supported in SQL Source Control. Basically the user has to separately log in to Team Explorer and lock the objects through the ui of this Microsoft tool, SQL Source Control will then respect these locks.
Once the changes have been made by the user they release the locks through Team Explorer and commit as normal. Currently you cannot lock objects through the SQL Source Control Ui.
If you are using the Shared Model then we are proposing that users lock the objects in SQL Server. The SQL Source Control team are currently designing this 'Safeguarding' feature which will allow you to do this through the tool. We have UI designs and some of the 'machinery' which will allow you do this and are currently exploring the direction of this feature.
Which option would suit you best?
Incidently SQL Source Control basically 'checks-out' the files in exactly the same way for each model. A local copy of the SQL objects are persisted to the users disk and put under the control of SQL Source Control which is using the TFS API under the hood.
More details can be found here:
http://documentation.red-gate.com/displ ... +overview#
Please do come back with any further questions about this or anything else to do with our products.
Thanks again for your interest, Surm.
Test Engineer, SQL Source Control