Take the 2-minute tour ×

Is there a way to disable the 'Keep my changes' button during check in?

For example:

When person A is altering class x.cs in visual studio 2010 that is under source control (TFS 2010), and person B is also altering class x.cs in VS2010.

And person B does check in his code, and after that person A wants to check-in his code, Visual Studio comes up with a message that there are conflicts:

Check In

No files checked in due to conflicting changes. Please use Conflicts Channel to resolve conflicts and try again.

Then person B can compare the code, discard his changes, but there is also a button to 'Keep Local Version'. If that button is clicked, the changes made by person A are lost.

To prevent this, I really like to know if it is possible to disable this button.

Or make a check-in policy or something to prevent this example from happening.

share|improve this question

2 Answers 2

I'm a little confused. I've never seen the "newer version" message-- at least not for .cs files. Are people checking out the files they are editing, or simply marking read-only files as writable so they can make changes?

Make sure in your source control options, that it is set to either automatically check out, or prompt you to check out when files are edited.

Overall, your best bet here is training and the use of frequent forward integration. Essentially, developers should be trained to always "get latest", resolve any conflicts, and then check in. That will eliminate this problem completely.

share|improve this answer
You are a little right. The 'newer version' message is really the message: 'Check In - No files checked in due to conflicting changes. Please use Conflicts Channel to resolve conflicts and try again. And after this message you can look at the 'channel' and choose Keep Local Version'. And the best way is that developers should always do a get latest, but some do not. So by enforcing this by disabling the 'Keep Local Version' button, could be a solution. –  Dennis Dec 10 '10 at 14:15

There's an old* saying that technical solutions to social problems rarely work. What you have here is a social problem - Person B is performing an action which is probably not what they intend. The solution should be a social one - encourage all your People to take responsibility for their checkins and above all to think while they're interacting with the shared source control system. All the policies in the world can't substitute for thinking.

Sure, you might say, but it would be nice to have a 'safety catch', or a warning mechanism, or whatever. To which I say - there already is one, and it's being explicitly acknowledged!

Also, what should happen when Person B's changes include and subsume Person A's, so they really do want to throw away the delta contributed by Person A?

(*) I found this reference from 2002, which is practically in Renaissance times for software development - I'm sure there are older

share|improve this answer
On the one hand you are right, it should be the responsibility of the developers. But, sorry for saying this, i'm not asking for anyone's opinion. I'm asking if it is possible to disable the button. But I do not think I will get an answer to my question. So I have to live with the knowledge that some developers do not think while checking in code, and also do not start to think when I've told them a thousand times. Also I cannot go to my manager to ask him to fire some persons because they do not think when checking in code... –  Dennis Dec 13 '10 at 7:52

Your Answer


