Red Gate forums :: View topic - Using a Shared Dev DB Model
Return to RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Source Control EAP
SQL Source Control EAP forum

Using a Shared Dev DB Model

Search in SQL Source Control EAP forum
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.
Jump to:  
Author Message

Joined: 19 Mar 2009
Posts: 125
Location: Cambridge

PostPosted: Thu Jun 17, 2010 11:00 am    Post subject: Using a Shared Dev DB Model Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
This topic is locked: you cannot edit posts or make replies. All times are GMT + 1 Hour
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2005 phpBB Group