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

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