Conflict on coworks workstation but not on mine

• 
  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.

  StephanieHerr March 19, 2010 15:31

  - 0 +

Add comment

Please sign in to leave a comment.