Is performing a Get Latest mandatory before checking in in TFS so you do not overwrite/lose code?

Question

There is a recurring issue in my team that is driving me nuts. People claim that some check-ins in Team Foundation Server are overwriting previous check-ins/existent code. They claim you always need to do a Get Latest Version before doing a check-in. In other words, running a get latest is a pre-requisite for a proper check-in.

I, in response, reply as follows: There must be a TFS definition/setting that we are missing/we left unchecked, if the described above is really happening. What would be the point in having a Version Control system that will not automatically warn you about code conflicts upon checking in (if before your check in someone else checked in different code than yours) ? I would understand if there were settings that set this or that behavior (check in regardless of what is there in the db now or warn if there are conflicts and prompt for action (merge)).

I want to understand: am I wrong ?! Is this simply the way TFS works ? Get Latest is mandatory before any check ins, no matter what ?!

As a side note, if checking in without manually running a get latest is risky and dangerous, why would Microsoft not make this the default behavior ?!

Thanks in advance!

Answer 1

I agree with @JamesReed that TFS always checks for conflicts rather than blindly overwriting another's work; that is after all the fundamental purpose of a version control system!

I also agree that deliberate user action (i.e. mistake) is the only way to overwrite a prior commit.

However, I disagree on an important point. James states:

The changes are in different parts of the file, so TFS attempts to auto resolve the conflict. I would expect this to be fairly safe and you would see both sets of changes. [Emphasis mine]

Yes, TFS will auto-resolve changes in different parts of a file but it is far from safe! Consider the following scenario. Developer A makes the change noted below and commits. Developer B, starting with the same original, makes a change in a different part of the file, and commits. TFS, or any version control system for that matter, will auto-merge quite happily, yielding broken code!

With that in mind, let me refine the original question into 2 stages:

1. Is Get Latest-before-commit mandatory to avoid losing code? No.
2. Is Get Latest-before-commit mandatory to maintain your code integrity? Yes!!

In summary, best practice demands that one should fetch the latest changes, then manually review your about-to-be-committed changes in the new context, then finally do your commit.

(For further reading, I wrote about this in detail referencing Subversion but it applies regardless of which VCS you are using: Subversion and TortoiseSVN Cookbook Part 1.)

Answer 2

I'd say doing a get latest is good practice, but not mandatory.

If I have a file that I've been modifying, and there is a more recent version held on the server.

• If I do a get latest, I would expect a conflict to be detected and I would be asked to resolve the conflict before my local file system is overwritten
• If I try to check the file in without doing a get latest I would expect TFS once again to detect a conflict and ask me to resolve it.

I've just tested this behaviour and this is what I see. I'm using TFS 2013 and VS 2013 with local workspaces. I'm certain that server workspaces behave in the same way.

The 2 scenarios that I can see that wouldn't follow this pattern are

1. The changes are in different parts of the file, so TFS attempts to auto resolve the conflict. I would expect this to be fairly safe and you would see both sets of changes.
2. The people checking in the second version of the file are misunderstanding the conflict resolution screen and selecting "Keep Local Version" when being presented with the resolution options.

I would say that it's safer to do the get latest, as you can build the code after resolving the conflict to make sure that you've resolved it without breaking the build, however if you have a strong CI process in place then this reduces some of the risk.

Edit: This is the documentation for get latest which states

Keep in mind that if you get an older version of a file, make changes to it, and then try to check it in, there is an increased chance that you will need to resolve conflicts before you can complete the check-in.

And this is the documentation on check in, which contains the following when discussing the outcomes of trying to check in a change

Conflicts block your check in. The system presents you with conflicts between your changes the latest version of the files on the server. .

Second Edit: You might find the comments on this question interesting. For Info Edward Thompson was a developer on the TFS team before he moved to github

Automerge is generally the same across all vendors, and there aren't any longstanding known issues there. That said, it may be helpful to turn it off (Tools -> Options -> Source Control -> Visual Studio Team Foundation Server -> Attempt to automatically resolve conflicts when they are generated)