Team Foundation Source Control won’t Get Latest when you Check Out

Published 23 November 06 03:45 PM | urig

In a recent post, Leon Langleyben described a Team Foundation Source Control "feature" that is giving users a hard time. The "feature" is that the Check Out command in TFSC no longer performs a Get Latest on the file checked out, as we were accustomed to in VSS.

In the older Visual SourceSafe, when you checked out a file VSS would get the latest version of the file to your local machine and only then open the file for you to work on. This is critical when working in Exclusive Checkout Mode, which is the most popular work mode in VSS. It guarantees that whoever starts working on the file picks up from the point his predecessor finished and not from some undetermined version in the past.

Having removed the implicit Get Latest operation from the Check Out command Microsoft has yet again shot itself in the foot by shooting its users in the stomach. Teams migrating to TFSC from VSS are taken completely by surprise by the fact that when a team member checks a file out he is not guaranteed to work on the latest version.

Most programmers I've talked this over with describe this new "feature" as a bug. It completely breaks their faith in TFSC as a reliable source control system. When basic trust in it is shattered, TFSC has very little chance of being accepted as the better successor of VSS. My team won't even consider the transition in light of the difficulties one of our team leaders experienced with TFSC in a different company.

How could the TFSC development team make such a terrible mistake? - A harsh usability error that impacts drastically on the marketability of their product. I believe that this happened because the TFSC development team was focused on cutting edge source control strategies and neglected to remember that most of their users are still fixated on the traditional Exclusive Check Out strategy.

Leon describes this as "one of VSTS source control features that is hard to explain to clients". This implies clients are thick headed and I don't think this is the case. I think Microsoft broke the client's expectations without proper warning and needs to fix things ASAP.

I am thankful that the TFSC development team has taken measures to remedy the situation in the next version by adding a "Get Latest on Checkout" command to the system.

תגים:, , , ,

Comments

# Eugenez said on November 24, 2006 06:44 AM:

Frankly, I think your comment misses a point. While that Get latest feature may seem a must (especially for clients migrating from VSS), it is hardly the thing that will define "go" or "no go" decision for TFS (even assuming that version control is only part of Team System that is going to be used). And while there may be lots of customers focused on "exclusive check out", TFS VC supports also multiple concurrent check outs (which is in fact a preferred approach with TFS). So is the absence of configurable option (Get latest on Check out - yes/no) is unfortunate, it is hardly that critical.

# urig said on December 5, 2006 10:07 AM:

Hi Eugene.

I'm not saying that Check Out with no Get Latest is a "no go" bug for the TFSC product. I am saying that it's a big mistake for Microsoft and I think it will have a significant impact on the adoption of TFSC as a replacement for VSS.

I base this on my experience - we have a team lead who swears against TFSC because he experienced the "bug" in his previous company. As a result, my department is reluctant to adopt TFSC. I think this must happen to many others as well.

In a way MS have acknowledged this by add the "Check Out and Get Latest" command to later releases.

# Shaun said on July 27, 2007 03:10 PM:

Eugenez, I feel very strongly on this issue and cannot agree with the author more. The IDE integration easily alows you to edit code by automatic check out 3 days later when checking in you all of a sudden you realize that you dont have the latest version. Some how certain ppl see this as ok, but frankly it is the most irritating thing ever. You now need to take time out of your project development to fix STUPID merge issues. So is merging a new defacto standard? Is it anticipated that you will have to merge code? And if so whos responsiblity is it to re-test code to ensure it still operates as designed. I have been developing for 10 years, I must be getting old, but I just cannot see the point of this .... I believe that working in a non-exclusive check out mode is just looking for trouble espeicially in larger teams using highly penetrated and cross framework code. IT DETRACTS from productivity. Maybe someone can explain how this acitvity is supposed to improve dev time? Maybe I got it all wrong.