A
Shared Development DB Model is when all developers connect to the same database server (hopefully using their own credentials) and develop directly against the same development database.
SQL Source Control will work on a Shared Model, but there are a few problems you should be aware of:
1) You may commit others’ changes.
On the Commit tab, you will see all changes to the database that are not in source control. The commit list is not limited to just your own changes. Since all changes are selected by default in the commit list, please be careful to unselect objects that you did not change and don’t want to commit. Someone else may still be in the middle of making changes and this should not be committed to source control yet.
Hint: If you only have one object that you changed and want to commit just this object, then right-click on that object in the Object Explorer and select commit. This will only select that specific object in the commit list and then you don’t have to worry about unselecting all the other objects.
2) You may not see your changes on the Commit tab.
This is because of the problem above. If someone else committed your changes, then you may not see anything on the Commit tab when you expect to.
3) You may see conflicts, which you should just ignore for now.
Conflicts do not make sense in a Shared Model. A conflict occurs in the Dedicated Model when a developer tries to commit a change to an object, but didn’t have the latest version of the object to begin with. Developers need to review the object to see what the latest version should be. It could already be correct in source control, or your database version might be correct, or you may need to have a combination of both changes.
In a Shared Model, you don’t need to worry about conflicts, but you may still see them. This happens because SQL Source Control maintains a local working folder for each developer and this working folder may get out of synch if you don’t visit the commit tab frequently. Once the developer who is working on the object commits it to source control and you visit the commit tab, then you will no longer see the conflict.
4) You may undo others’ changes.
The undo feature allows you to undo any changes made to the database that are not in source control. If you undo someone elses changes, you may actually revert the object back to a really early version depending on when you last committed to source control. This could be confusing to the user that is currently working on that object. Be careful to only undo the objects that you are working on.
We hope to improve these areas in a future release, but still
recommend switching to a Dedicated Model.
SQL Source Control will work on a Shared Model, but there are a few problems you should be aware of:
1) You may commit others’ changes.
On the Commit tab, you will see all changes to the database that are not in source control. The commit list is not limited to just your own changes. Since all changes are selected by default in the commit list, please be careful to unselect objects that you did not change and don’t want to commit. Someone else may still be in the middle of making changes and this should not be committed to source control yet.
Hint: If you only have one object that you changed and want to commit just this object, then right-click on that object in the Object Explorer and select commit. This will only select that specific object in the commit list and then you don’t have to worry about unselecting all the other objects.
2) You may not see your changes on the Commit tab.
This is because of the problem above. If someone else committed your changes, then you may not see anything on the Commit tab when you expect to.
3) You may see conflicts, which you should just ignore for now.
Conflicts do not make sense in a Shared Model. A conflict occurs in the Dedicated Model when a developer tries to commit a change to an object, but didn’t have the latest version of the object to begin with. Developers need to review the object to see what the latest version should be. It could already be correct in source control, or your database version might be correct, or you may need to have a combination of both changes.
In a Shared Model, you don’t need to worry about conflicts, but you may still see them. This happens because SQL Source Control maintains a local working folder for each developer and this working folder may get out of synch if you don’t visit the commit tab frequently. Once the developer who is working on the object commits it to source control and you visit the commit tab, then you will no longer see the conflict.
4) You may undo others’ changes.
The undo feature allows you to undo any changes made to the database that are not in source control. If you undo someone elses changes, you may actually revert the object back to a really early version depending on when you last committed to source control. This could be confusing to the user that is currently working on that object. Be careful to only undo the objects that you are working on.
We hope to improve these areas in a future release, but still recommend switching to a Dedicated Model.