Issue with committing a rolled-back object
CraigEddy
Posts: 36 Bronze 3
We're using TFS as our repository. At some point, someone accidentally checked in (via SQL Source Control) a bogus copy of a stored procedure.
Instead of reverting the script/object in SSMS, I used the TFS "rollback changeset" feature to roll back the checkin on the stored procedure's file in the source control tree.
Now I have made a change to that stored procedure and when I try to commit the change, SQL Source Control errors out telling me that there are conflicts which must be resolved. However, there are no conflicts listed in the Get Latest tab and, conceptually, there isn't a conflict in place.
To fix the problem, I used TFS to check-out the stored procedure's script file, edited the script file, checked it back in (again via TFS), and then the object no longer appears on the Commit Changes tab.
This seems like a bug to me. I sent a bug report from the UI (email address is same as on my forum account).
Thanks,
Craig
Instead of reverting the script/object in SSMS, I used the TFS "rollback changeset" feature to roll back the checkin on the stored procedure's file in the source control tree.
Now I have made a change to that stored procedure and when I try to commit the change, SQL Source Control errors out telling me that there are conflicts which must be resolved. However, there are no conflicts listed in the Get Latest tab and, conceptually, there isn't a conflict in place.
To fix the problem, I used TFS to check-out the stored procedure's script file, edited the script file, checked it back in (again via TFS), and then the object no longer appears on the Commit Changes tab.
This seems like a bug to me. I sent a bug report from the UI (email address is same as on my forum account).
Thanks,
Craig
Comments
Making manual modifications to the repository outside of SQL Source Control can sometimes cause the add-in to become a bit confused and behave strangely. It's not really serious and you can normally resolve it by unlinking and relinking the database to source control.
It's a bit of a pain needing to do this so we're looking for ways to make this process a bit simpler. We should really be able to handle these kind of conditions, but sometimes it can go wrong.
Can you replicate this problem? I didn't get the same issue when I followed your steps. After you completed the roll back, did you update your local database using 'get latest' before you attempted to commit another change?