前两天讨论Source Code老是被同事覆盖的问题时，发现在VS中开始编辑时自动Check Out的代码居然不是Latest Version，吓了一大跳，潜意识里觉得这是一个很严重的Bug，因为在VSS, CVS等版本控制系统中，但Check out的时候都会自动获取最新的版本。

而后查了MSDN Forums和相关的blog，发现居然说是TFS的By Design。按TFS团队的说法，这是基于如下考虑：

1.假定TFS Server上的代码总是一个完整的可用的Build，也就是说每个员工必须保证你的一个完整的Check In是必须可以Build成功的。

2.通常意义上，你开始新的工作的时候同样应该确保你的本地版本是可以通过Build的。当然可能是跟Server上最新的版本同步的，也可能是Server上某个时刻的SnapShort，总之是一个好的版本。

3.当你需要编辑代码的时候，Check out这个动作只是做了个Editable的标记而已。如果发现Server上有新的版本，只是提示你Server上的版本比你的Local版本要新，而不是Get Lastest Version。为何呢？因为通常意义上来说，如果Server上有一个新的版本，意味着有了一个新的ChangeSet，而一个ChangeSet并不是只有一个文件，如果你只是把正要编辑的版本Get Lastest Version，由于Code的依赖关系，很可能导致本地编译被Block。

4.为了避免开发人员陷于此种陷阱，TFS团队决定不是直接Get Lastest Version，而是在你完成了代码工作后要Check In的时候告诉你有Conflict,需要再做Merge来。这样在Check In的时候开发人员必须仔细的对比检查，做好Merge工作才能确保在你Check In之后Server上又是一个好的Build。Merge的时候注意千万别把别的开发人员的Code给覆盖了。

这种新的设计对于已往使用VSS，CVS的开发人员来说习惯上可能一时很难转变，特别是在不知情的情况下很容易犯错。微软答应会在TFS的第二版本中会提供是否自动Get Latest的选项。

PS：由此可见，Check in(CVS里对应术语是Commit)的时候在TFS里的Conflict的概念跟CVS里的Conflict还是有所区别的。在CVS 里，Conflict意味着无法自动Merge，而在TFS里，Conflict只是告诉你Server上有比你当前更新的版本而已，你可以选择自动 Merge、忽略本地版本、覆盖Server上的版本，或者对比后手工Merge重新提交。

可以参考获取更多详细信息。