5

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!

Veverke
  • 9,208
  • 4
  • 51
  • 95

2 Answers2

6

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!

Auto-merge gone wrong

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

Michael Sorens
  • 35,361
  • 26
  • 116
  • 172
  • Thanks for adding your bit to the discussion, Michael! – Veverke Dec 03 '15 at 17:28
  • *yielding broken code*: I do not think this is a correct affirmation, since the code is not broken. It generates, however, a runtime error! Bottom line: the VCS cannot break code alone on his own, otherwise we should hastily notify their product has a bug and... stop relying on 3rd party software and start writing everything in our own :-) – Veverke Dec 03 '15 at 17:31
  • *Is Get Latest-before-commit mandatory to maintain your code integrity?* - code integrity sounds better, but still - code integrity I would associate with the ability of the code to compile or not. The point is the VCS must very likely be responsible for whichever known validation algorithms beforehand - since the conditions to make a code compilable or not have nothing to do with what the code does - the VCS can be responsible for that, and I hope (believe) it is. It can't, indeed, be tasked with making sure the code produces correct results, since it will never have a way of knowing that. – Veverke Dec 03 '15 at 17:36
  • I did say _fairly_ and perhaps safe wasn't the correct word, but it won't overwrite changes it will merge them gracefully, which is the point of the question :-) I also mentioned having a strong CI process, which would include comprehensive unit tests to highlight the issues you describe. Right tool for the job and all that. – James Reed Dec 03 '15 at 20:46
  • I quite agree, @JamesReed. I understand your answer was quite appropriately addressing the gist of the question; just wanted to point out that there could be other issues along the way as well. :-) – Michael Sorens Dec 03 '15 at 21:52
5

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)

Community
  • 1
  • 1
James Reed
  • 13,873
  • 51
  • 60
  • First of all, thanks James for your addition. Bottom line: your understanding is that, the only way a check in would replace existing code is by user mistake, while taking whatever conflict resolution action in the conflict resolution prompt ? – Veverke Dec 03 '15 at 10:32
  • Does it not sound logic (and the contrary even absurd) that I took care of building you a control version system so to take all those worries from you - and whenever you need change any of the files being tracked you need to manually make sure they are the latest ?! Otherwise all TFS is is simply a static database of files and why call it control version system in the first place?! – Veverke Dec 03 '15 at 10:34
  • Yes. I would expect TFS to warn you either way, and for it to be a concious decision to ignore the warning and check in the code. Whilst TFS has certain limitations over other VCS, in this regard it's pretty robust. – James Reed Dec 03 '15 at 10:43
  • I appreciate your time in leaving your insights here. I hope others will drop some lines too, as this discussion is really very frustrating and irritating. If you claim something, you **have** to give a reason for why you think that way - and obviously something other than **because that's the way it is**. I have mine and provide what supports it, I am waiting for different opinions to support them. I will take the outcome here to my team at the end. – Veverke Dec 03 '15 at 10:46
  • 2
    I'd guess people are getting prompted to resolve conflicts, but are messing up the resolution. This is usually the case when people make similar claims, often going away saying something like, "oh, I think I know what it might have been...", but never elaborating :) – DaveShaw Dec 03 '15 at 11:26
  • @Veverke you seem to be wanting some evidence in my answer for this behavior. I've updated my answer – James Reed Dec 03 '15 at 20:59