在TFS登记之前是否执行Get Latest强制要求,以免覆盖/丢失代码?

时间:2015-12-03 09:45:50

标签: tfs

我的团队中经常出现一个让我疯狂的问题。 人们声称Team Foundation Server中的一些签到会覆盖以前的签入/存在代码。 他们声称在办理登机手续之前您总是需要Get Latest Version。 换句话说,运行get latest是正确办理登机手续的先决条件。

我作为回应回复如下: 必须有TFS定义/设置我们缺少/我们未选中,如果上面描述的确实发生了。有一个版本控制系统,会在办理登机手续时自动警告您有关代码冲突的问题(如果您在检查其他人检查的代码不同于您的代码之前),会有什么意义?我会理解是否存在设置此行为或该行为的设置(无论现在数据库中存在什么,都会检入,或者警告是否存在冲突并提示操作(合并))。

我想明白:我错了吗?这只是TFS的工作方式吗?在任何检查之前,Get Latest是强制性的,无论如何?!

作为旁注,如果在没有手动运行get latest的情况下签入是危险且危险的,为什么Microsoft不会将此作为默认行为?!

提前致谢!

2 个答案:

答案 0 :(得分:6)

我同意@JamesReed,TFS 总是检查冲突,而不是盲目地覆盖他人的工作;这是版本控制系统的所有根本目的!

我也同意故意的用户操作(即错误)是覆盖先前提交的唯一方法。

但是,我不同意一个重要观点。詹姆斯说:

  

更改位于文件的不同部分,因此TFS会尝试   自动解决冲突。我希望这个是相当安全的和   你会看到两组变化。 [强调我的]

是的,TFS会自动解决文件不同部分的变化,但这远非安全!请考虑以下情况。开发人员A进行如下所述的更改并提交。开发人员B,以相同的原始文件开始,在文件的不同部分进行更改,并提交。对于这个问题,TFS或任何版本控制系统都会非常愉快地自动合并,从而产生破碎的代码!

Auto-merge gone wrong

考虑到这一点,让我将原始问题细化为两个阶段:

  1. Get Latest - 在提交前强制要求以避免丢失代码吗?
  2. Get Latest - 在提交之前是否必须保持代码完整性? 是!!
  3. 总之,最佳实践要求应该获取最新更改,然后手动检查新上下文中即将提交的更改,然后最终执行提交。

    (为了进一步阅读,我详细介绍了Subversion,但无论您使用哪种VCS,它都适用:Subversion and TortoiseSVN Cookbook Part 1。)

答案 1 :(得分:5)

我说做最新的做法是好的做法,但不是强制性的。

如果我有一个我一直在修改的文件,并且服务器上有更新版本。

  • 如果我收到最新消息,我会发现会检测到冲突,我会被要求在覆盖本地文件系统之前解决冲突
  • 如果我尝试在没有获取最新信息的情况下检查文件,我会期望TFS再次检测到冲突并要求我解决它。

我刚测试过这种行为,这就是我所看到的。我正在使用TFS 2013和VS 2013与本地工作区。我确信服务器工作区的行为方式相同。

我可以看到的不符合此模式的两种情况是

  1. 更改位于文件的不同部分,因此TFS会尝试自动解决冲突。我希望这是相当安全的,你会看到两组变化。
  2. 检查文件第二版的人员误解了冲突解决屏幕,并在显示解析选项时选择“保留本地版本”。
  3. 我会说获取最新版本更安全,因为您可以在解决冲突后构建代码以确保在不破坏构建的情况下解决它,但是如果您有一个强大的CI流程,那么这减少了一些风险。

    编辑: This是获取最新状态的文档

      

    请记住,如果您获得较旧版本的文件,对其进行更改,然后尝试将其签入,则在完成签入之前您需要解决冲突的可能性增加

    this是签到时的文档,在讨论尝试签入更改的结果时包含以下内容

      

    冲突会阻止您的签入。系统会在您更改服务器上的最新版本文件之间向您显示冲突。

    第二次编辑: 您可能会发现this question上的评论很有趣。对于Info,Edward Thompson在转移到github之前是TFS团队的开发人员

      

    所有供应商的Automerge通常都是相同的,并且那里没有任何长期存在的已知问题。也就是说,关闭它可能会有所帮助(工具 - >选项 - >源代码管理 - > Visual Studio Team Foundation Server - >尝试在生成冲突时自动解决冲突)