Red Gate forums :: View topic - Conflict on coworks workstation but not on mine
Return to www.red-gate.com RSS Feed Available

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

Conflict on coworks workstation but not on mine

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
ceacl



Joined: 03 Jun 2009
Posts: 12

PostPosted: Fri Mar 19, 2010 5:24 pm    Post subject: Conflict on coworks workstation but not on mine Reply with quote

We have a team of 4 developers using this tool in a shared DB environment and are experincing Conflict issues quite frequently even though the conflicted object(s) in question had not been changed by anyone else.

Even after several attempt we haven't been able to reproduce this issue. It appears to happen randomly.

Have there been any other reports of this happening or any insight into what is causing it?
Back to top
View user's profile Send private message
sherr



Joined: 19 Mar 2009
Posts: 125
Location: Cambridge

PostPosted: Fri Mar 19, 2010 8:31 pm    Post subject: Conflict on coworks workstation but not on mine Reply with quote

We can provide some insight into why this is happening...

Each user is working directly on the same db and committing to source control from SSMS, but each user also has their own underlying working folder on the file system, which is NOT shared.

This "conflict" problem will occur if a user's underlying working folder is out of synch. This occurs if a user doesn't visit the commit tab when the db matches the latest version in source control. This means user 1 changes an object and commits it. User 1 then makes another change to the same object, but doesn't commit it yet. User 2 now visits the commit tab for the first time since user 1's initial commit. User 2 will see a conflict because their underlying working folder is out of date.

User 1 will never see a conflict because their working folder is in synch. Once user 1commits the table and user 2 revisits the commit tab, the conflict will disappear and both users' working folders will be in synch.

This probably explains why the conflict appears on your co-workers workstation and not your own. Were you the one that made changes to the object? Did you make changes commit and then make more changes?

We'd really like to know how many other people are experiencing this problem and how often you experience this problem. How serious is this problem for you? Would this prevent you from using SQL Source Control?

For now, please just ignore these conflicts if you are on a shared DB environment. It only means that there have been multiple changes to the same object since you last visited the commit tab. Once the user commits his/her current changes, the conflict should disappear for the other users.

I hope this makes sense. Our internal tracking number for this issue is SOC-854.
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