Just to note, SQL Source Control is still in an early access phase and we do not
recommend using it on Production DBs.
Your situation is kind of unique since you do not have a dev db...
I don't understand exactly what you are trying to do.
It sounds like you are using Visual Studio and editing the CREATE script files directly. The whole purpose of SQL Source Control is that you can continue to work directly on your db within SQL Server Management Studio, so that you don't have to worry about the CREATE scripts and SQL Source Control generates them for you. If you do make a change in VS and commit it, then you should see this on the Get Latest tab and you can click the "Get Latest" button to update the db. What do you mean that you cannot "Get Latest?" Please be careful that the SQL syntax within the script is correct. This is why it is better to just work directly on the db.
It's true that changes to the db do not automatically get committed to source control. This requires discipline from the db developer to commit the change. We would like them to supply a comment when commiting so others can understand why they made the change. SQL Source Control helps by placing blue indicators on the ObjExp, which reminds you that you have made changes that you haven't commited yet.
You can use SQL Compare Pro to automatically check that your production db is at the version you expect it to be. This is retroactive, but allows you to see if any changes are made directly to prod that were not expected. These changes can then be applied back to your dev db and committed to source control if that's what is decided.
I hope this helps! Please let me know if you are still having problems getting changes from TFS to your db.
Stephanie M. Herr
SQL Source Control - Project Manager