作为源代码控制工具的TFS：你喜欢什么？你讨厌什么？

Question

作为源代码控制工具的TFS：你喜欢什么？你讨厌什么？

tfs

17

我已经使用TFS大约18个月了，但我对它并不感到兴奋。它似乎是目前市场上最差的版本控制系统之一。

我认为这篇文章将帮助人们决定是否选择TFS而不是其他源代码控制系统。虽然TFS做的事情远不止如此，但我认为源代码控制对软件开发非常重要，因此您选择的任何系统（或其组合）都需要首先考虑源代码控制。

TFS相对于其他源代码控制有哪些优点-它比别人做得好在哪里？

TFS有什么短板-与其他系统相比，它做得不好的方面是什么？

- jcollum

11

在我看来，你更希望得到一个“有罪”判决，而不是进行讨论。 - Oded

3

我不知道最糟糕的是什么。你尝试过ClearCase吗？（我并不想在这里开始争论，我只是不得不在工作中使用CC，而且不是一个满意的客户）我同意，源代码控制对于软件开发非常关键。如果有人需要花一周时间才能接入某个东西，那么那就不是正确的解决方案。好问题。 - Rob Goodwin

5

你听说过Serena Dimensions吗？与之相比，TFS只是一个梦想。 - Oded

1

VSS或CVS怎么样？我认为TFS至少比它们更先进。 - Tom Cabanski

我最近换了工作，从Git（Bitbucket）转到了TFS。我非常想念我的Git Bash控制台。我正在努力保持开放的心态，学习这个新的源代码控制系统，但是很困难。至少可以说我必须要用回Git...<---黑眼豆豆的参考？ - Wjdavis5

显示剩余14条评论

12个回答

13

不喜欢

除非你将文件检出，否则不会追踪对文件的更改。因此，如果在Notepad++中编辑文件，则TFS不知道任何更改。
有人很容易检出文件并将其锁定，以使其他人无法进行更改。 TFS不应该放弃这种能力，但它肯定应该比目前更难做到。
撤消一项或两项提交的方法非常不清楚，以至于我总是不确定是否起作用了。
TFS使文件变成只读状态，除非你将它们检出，这种方式让人感到讨厌，但它确实帮助我记得在保存所做的编辑之前检查文件。

喜欢

如果你喜欢这样的东西的话（我不喜欢），那么内置的Visual Studio集成功能是不错的。

- kubi

2

从第四点开始（与第一点相关），锁定它们并明确检查它是有意义的，这也是其中一个很好的原因。在您开始处理文件之前，您没有暗示的“所有权”。如果“修复”锁定对您的团队非常重要，请与管理员讨论拒绝锁定权限的问题。至于“撤消”，我很高兴它实际上不是内置的，除了从命令行回滚。 “撤消”会更改历史记录。我宁愿看到开发人员签出以前的版本，并强制执行检入，解释他们为什么要做某事。 - Joseph Ferris

1

回应你的第一个观点，我不明白为什么需要锁定和签出，或者它能给我带来什么好处。当我编辑文件时，为什么TFS不能自动检查并签出文件呢？当我通过Visual Studio编辑文件时，它会这样做，当我在IDE之外编辑它们时，它也应该这样做。 - kubi

@joseph：撤销上一次的签入将非常有用-通常会签入，然后意识到您在列表中勾选了某些您不想签入的内容。“撤销”最近的更改集不会“更改历史记录”-如果正确实现撤销后，您仍将检出更改，并且可以纠正错误并签入您打算签入的内容，就像您只是在提交签入之前按下“取消”一样。 - Jason Williams

@joseph：在这种情况下，撤销操作应该是基于权限的。TFS团队似乎已经决定它不重要到足以混乱他们完全极简的用户界面。就像虚拟文件共享一样，他们认为这对普通开发人员来说太强大了。 - jcollum

1

讨厌的编程错误 #1 真是噩梦。每天因此感到非常生气。 - Arnis Lapsa

显示剩余8条评论

9

我是微软团队基础设施服务(Team Foundation Server)的成员。这里提出了很多非常有价值的问题，其中一些在2010年版本中得到了解决。其他问题仍然存在，但我们认识到它们，并正在努力改善下一个版本的开发人员体验。像这样的讨论对于帮助我们确保解决正确的问题非常有帮助。

以下是至少部分在2010年版本中得到解决的问题的信息:

独立客户端

对于希望在VS之外使用该产品的非开发人员客户，他们可以使用Windows Shell扩展powertool。

如果您有需要从非Windows机器访问TFS的用户(无论是开发人员还是非开发人员)，他们可以使用Team Explorer Everywhere。这支持包括Mac和Linux在内的平台。

复制工作区

今天有两种方法可以复制工作区。第一种是使用命令行中的工作区模板命令。例如：

Tf /workspace /new /template[工作区名称/要复制的所有者]

或者，您可以在UI中打开一个工作区，选择所有映射，将它们复制，然后粘贴到文件/电子邮件中。然后，其他人可以将这些相同的映射粘贴到他们的工作区中。

如果您可以简单地指定客户端自动接收的默认工作区，那肯定会很好，但我们今天还没有这个功能。

合并健壮性

在TFS 2010中已经解决了描述的场景，在进行添加、重命名、添加等操作时，当您进行合并时会遇到问题。

分支/合并为一流体验

在TFS 2010中，分支现在是TFS中的一流对象。您可以可视化您的分支，甚至跟踪它们通过分支的变化。分支也是基于快速服务器的操作。

获取多个项目的最新版本

您可以通过选择源代码控制资源管理器中的TFS实例节点，然后选择获取最新版来完成此操作。这相当于根目录($)

文件锁定

默认情况下，当用户检出文件时，TFS不会锁定文件。这是我们在微软使用TFS的方式，也是我们看到大多数客户使用TFS的方式。可以让用户显式锁定文件。有些客户认为这很理想，但这不是默认的路径体验。

- Jamie Cool

默认情况下，当用户检出文件时，TFS不会锁定它们，但这完全取决于文件类型。RPT文件（CR）在检出时始终被锁定。 - jcollum

谢谢@Jamie，听到积极支持我们的开发人员的声音总是很好的，而不仅仅是听我们抱怨我们不喜欢的东西 :-) TFS/VSTS正在不断改进，我只希望微软能投入更多资源，并帮助你们更快地使它变得更好！2010年的新功能听起来很棒（特别是分支）-我只是在等待我的新服务器到达，这样我们就可以升级我们的TFS，以便我们可以利用它。 - Jason Williams

6

缺点: 检出模式。许多应用程序无法很好地处理被标记为只读后变为可写的文件（如Word 2007、记事本）。所以你打开一个文件，编辑它，尝试保存，然后告诉你不能保存，因为它是只读的。太棒了，现在你必须另存为...，删除原始文件并将新文件重命名为旧文件名。如果有一个让本地文件成为只读的优点，我没有看到它。我真的更喜欢Subversion的方法。

唯一让文件变为只读的好处是它提醒你检查它们。但是这实际上只是检出模型的症状。

- jcollum

在我看来，这是那些不能正确处理这种情况的应用程序的问题。 - antred

3

我认为TFS是目前市场上最好的ALM产品。仅从源控制平台来看是片面的。我在我的职业生涯中使用过许多产品：VSS、SVN、Git、StarTeam、CC/Harvest和ClearCase，除了TFS。就个人而言，想到回到除TFS之外的任何其他产品，我都感到不安。

TFS是一个非常强大的平台。我遇到的最大问题通常与人们不知道如何使用它或者错误地使用它有关。它并不意味着成为一个“只是工作”的应用程序。当然，你可以在不学习太多关于它的内容的情况下将其用于基本的源控制，但如果你只是用它做这些，那么你真的最好使用其中一种不太强大的工具。实际上，TFS不能给你的是以你想要的方式解释功能的方法。它是从头开始专门构建支持流程而不仅仅是存储库。

- Joseph Ferris

我完全同意2005到2008这个版本的观点，但我在2010中每天都发现很多新功能。就在今天，我无法在2008中检查一个货架集，所以我打开了2010，它检测到了2008无法处理的工作区冲突。分支和合并现在也非常方便。而团队构建更是让我惊叹不已。我认为他们知道有很多事情要做，关键在于把精力放在哪里。他们确实解决了上一个版本中的一些大问题，只是没有全部解决。假设玛雅人预言不成立，那么在2012年一切都将变得更好。;-) - Joseph Ferris

1

考虑到它的价格，它应该是一种最好的源代码控制和应用生命周期管理工具。但实际上它并不是。对我来说，这不是关于用户界面。而是关于TFS源代码控制团队所做的与每个其他软件配置管理团队不同的决策。在源代码控制领域中，TFS是一个古怪的存在。 - jcollum

此外，我的问题明确指出“TFS作为源代码控制”。而你选择说“是的，但它也是一个ALM！”。-1 - jcollum

@joseph：我们正在使用VSTS2010，但是在接下来的几个月内我们不太可能升级我们的TFS服务器，所以我们只能使用TFS 2008。2010对于分支看起来确实更好。 - Jason Williams

@jcollum：请随意给我的答案打分，但事实很简单——仅用TFS作为源代码控制是浪费金钱。至于它不是“最佳的ALM”，我会强烈反对你的观点。你提到的产品都不是ALM。很抱歉你不喜欢这个答案，但事实很简单，如果你不使用ALM功能，那么你可能只能使用VSS。为TFS付费并仅将其用于源代码控制是浪费，纯粹而简单。 - Joseph Ferris

显示剩余6条评论

3

缺点: 时间戳。TFS没有设置选项可以将远程最后修改时间戳作为本地最后修改时间戳。本地文件的时间戳只能告诉我获取该文件的时间。如果我获取了一个两年前的文件，就无法根据本地时间戳知道这一点。

我使用过的其他源代码控制工具都有这个功能。

- jcollum

我认为在微软的工具集环境中，这不是一个理想的功能。MS C++构建工具使用文件日期来扫描依赖项的更改，从而导致重新编译。如果您修改了一个文件，进行编译，将修改后的文件恢复到源代码控制（使用您的文件日期功能），然后重新编译，您仍将拥有带有修改版本文件的二进制文件，因为根据文件时间戳测量，源文件比二进制文件旧。 - David Gladfelter

好的，对于C++来说并不理想。对于其他人来说呢？也许可以。我绝对想要它。至少把它作为一个选项来设置。 - jcollum

3

缺点:

工作区版本：你无法在不进行递归搜索的情况下确定工作区的版本。
可怕的离线体验。attrib -r + tfpt在线上工作不应该是离线工作的方式。给我像git一样的东西，可以让我跟踪状态、撤消和进行更改。即使只存储工作区版本和当前版本之间的差异，我也没问题。
合并的稳定性：服务器上的已更改文件+本地编辑的不同行不是冲突。可写文件不应该自动成为冲突。自动合并按钮不应该存在，因为这永远不应该是一种情况。
工作区：能够重新排列源结构的想法很奇怪，会引起问题。要求映射两个分支才能合并是奇怪的。如果我的工作区映射没有真正的根文件夹，则需要执行多次操作的要求是错误的。
完全依赖于远程服务器：将所有这些东西存储在服务器上有一些好处，但实际上，您可以在需要时在本地存储信息，然后上传它。在本地保留待处理更改、工作区映射、基本撤消历史记录等。

优点

存储区：我喜欢这些，希望也能将其支持到本地磁盘上（想想git stash）
VS中的源代码控制视图：能够在不下载整个仓库的情况下查看整个仓库真的很酷。虽然存在一些可用性问题，但总体思路还是很棒的。
工作区：没错，在两个地方。虽然重新排列仓库很奇怪，但只下载所需内容的能力非常棒。我经常希望我可以选择一个根文件夹，然后勾选我需要的路径，但没关系。

- Jim Deville

2

不喜欢：

使用历史记录来查找已完成的工作是非常繁琐的。您必须单击每个历史记录条目才能查看更改了哪些文件，然后您需要通过上下文菜单获取差异。
在断开网络连接的情况下工作是绝对不可取的。你有没有听说过在飞机上工作？
当您在VS之外处理文件时（例如TortoiseSVN），没有Windows资源管理器集成。
流程方法论者（配置管理员）喜欢不允许共享检出。这对于需要修改进行测试的配置文件来说绝对是一场灾难。
SC对于复杂的移动/删除操作容易混淆。
SC无法识别已检出文件未发生更改的情况。例如，服务引用更新会检出所有相关文件，并经常重新生成完全相同的内容。这些文件应该默认从检入中删除，因为它们只会在以后查看更改集时添加噪音。

喜欢：

暂存。

有人猜到我最喜欢的SCM系统是哪个吗？ SVN + TortoiseSVN + VisualSVN :-)

- Christoph

是的，无法获取差异报告的能力很糟糕。大多数其他版本控制系统都有这个功能。 - jcollum

您可以通过右键单击文件夹并选择比较来进行批量比较。我相信 tf folderdiff 也可以实现同样的功能。 - j.i.h.

1

在TFS 2010中未实现搜索功能？在VSS中，我们可以在文件中搜索；在TFS 2008中，我们可以搜索文件...

- muralidharan TR

1

缺点：如果您想将多个文件移动到现有位置的子文件夹中，您必须逐个操作。哇，这太糟糕了。

- jcollum

除非你想要进入命令行，否则在TFS中经常会发生这种情况。想要做一些稍微不同寻常的事情吗？命令行。 - jcollum

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jason Williams · Accepted Answer

优点

从根本上说，它是一个可靠的系统，稳定性很强。
与工作项、报告等集成。
强大的工具非常好用。
[编辑] 它不断改进，并且在2010年、2012年和2013年有了很大的进步。
TFS对自定义工具非常开放。有丰富的API使编写仪表板和其他工具以获取TFS中的数据变得非常容易。由于所有数据都存储在SQL中，因此如果需要，可以直接浏览和查询它们。多年来，我已经使用过许多不同的SCM，但从未发现像TFS这样开放和易于访问的SCM - 一切（用户故事、任务、缺陷、问题、测试计划、迭代、源代码控制和分支、构建、单元测试、持续集成）都近在咫尺。这是TFS的一个很棒的功能。 TFS的许多UI问题在为我的团队编写工具和仪表板的几个下午中得到解决。面对现实吧，如果你自己编写，它就能做到完全符合你的需求。

缺点

有一个领域它的可靠性极差：如果您在“一步”中对文件应用了多个更改（添加、重命名、编辑），它会变得非常混乱。如果您不单独检查这些操作，TFS2005和TFS2008 崩溃，当您将这些更改合并到分支时。从2010年开始，它不再崩溃，但它经常无法正确地检入更改，因此您必须进去清理缺失和名称不正确的文件。

没有独立的源代码控制浏览器。它集成在VS中，当您想要仅处理源代码控制项而不需要运行另一个VS副本时，这真的很恼人。当然，您可以给您的艺术家一个Team Explorer，但让我们问自己，只想查看文件、签出、签入和GLV的艺术家是否真的需要运行复杂的VSTS实例才能实现呢？此外，集成太差，以至于您无法从解决方案资源管理器真正实用地使用TFS（它仅关于您已检出的内容是假的，并且在该窗口应用操作时非常不可靠，因此您很快就学会了打开源代码控制窗口并在其中工作，这违背了首次集成的意义）[编辑：文件浏览器扩展非常出色-接近独立浏览器-并且简单易用。它的主要缺点是缺少与文件命令的正确集成-重命名或删除文件时必须记住使用TFS子菜单，否则您将本地重命名/删除文件，并且这会完全破坏源代码控制，因为TFS不知道您所做的更改。这不幸地意味着只有“高级”TFS用户可以信任使用它。因此，对于大多数用户而言，仍然是“没有独立浏览器”的情况。

用户界面不好（但至少在Web访问方面正在改善）。当然，它可以工作，但有很多事情可以做，使其更有效、愉悦和更易于使用。例如，在2012年之前，单击“签入”会选中所有未签入的项目，以便如果您以后意外单击“再次签入”，它会签入您不想要的所有内容。之后，可以提供“撤消上次签入”选项，以快速恢复它，但却没有这样的选项。（UI已经改进，但在VS2010中仍存在这些特定问题，尽管现在它确实有一个签入确认对话框，减少了意外签入的风险。）[编辑：在2012年，它变得更好了，但是他们疯狂地将所有单独的TFS对话框合并到一个窗口中，这是一大步退步。挂起的更改窗口不像在2010年那样好用——很难找到东西，需要更多的点击才能实现相同的事情，并且如果您从任何位置签入文件，则当前“包括”的所有文件都被扔到“排除”中，因此如果您有几个事情在进行中，它们都会混合在一起。]
工作区。在大多数情况下，每个团队成员必须具有基本相同的工作区映射，以在本地根文件夹下进行从属。我们需要定义7个映射，这需要大约5分钟来设置。没有办法从服务器推送工作区定义。没有[编辑]易于[/编辑]复制工作区的方法，因此您可以使用现有工作区（或其他用户的工作区）作为起点。不，您必须一遍又一遍手动重新输入所有绑定。如果您在源代码控制资源管理器中更改活动工作区，则它不会与待处理更改窗口同步，因此您会花费15分钟想知道为什么您从其他分支合并的文件未列出。（随着2010/2012的改进，您可以更轻松地查看其他PC上的工作区并复制和粘贴它们，但UI仍然相当笨拙。）
它有变更集，但是你不能像Perforce那样将项目捆绑到独立的变更集中，在您的待处理签入列表中，您只能通过实际签入将它们与变更集关联。您真的只能一次处理一个变更集，否则您必须手动将文件在待处理列表中分离开来进行签入。（在2012年仍然非常差。）合并工具很糟糕。它们根本不起作用，如果你依赖自动合并，它们还会不必要地引入错误到你的代码中。这些工具和我1994年第一次使用SourceSafe时一样糟糕。所以，在购买了一个非常昂贵的VSTS许可证后，你需要用真正有效的东西替换合并工具。这意味着每次出现合并冲突时，你必须选择每个文件，选择解决冲突并确定，然后选择使用第三方合并工具并确定，再进行合并，保存，然后选择接受已合并的更改。（你应该能够选择“自动合并”，并且它应该简单地使用实际有效的第三方合并工具，而不会让你遭受一连串无意义和恼人的对话框的轰击，它们总是默认为错误选项）[编辑：在VS2010中，合并工具仍然很糟糕。但前端UI大大改进（现在只需单击一下即可合并冲突，而不是4或5次点击-当你需要合并多个文件时，这是一个巨大的改进）。[在2012年有进一步的改进，但仍然“可以”而不是好的]

它不能在运行的VS实例之间同步。因此，如果你在一个VS中检入一个文件，另一个VS仍然会列出该文件在待检入的列表中。（显然很容易同步，因为power tools windows-explorer扩展程序所做的任何更改都会立即反映在VS中）[编辑：在2012年，他们解决了这个问题。现在每次切换到待定更改视图时，它都会花费15秒钟进行刷新（在2010中，它将其缓存并立即显示，但有时过期）]

分支是现在的标准工作方式。因此，你希望分支/合并工具能够快速轻松地完成这项工作。但事实并非如此。[编辑：在2010年和2012年进行了大幅改进，但合并支持非常糟糕-真的需要耗费很多精力。只有一些小的事情，比如只能合并连续的一组更改，因此，如果你想合并5个不连续的更改，你必须逐个完成它们，但每次打开对话框时，它都从头开始而不记住你上一次合并的进度、可用的更改集列表等，应该能够选择任何你想要的更改集，并自动完成剩下的工作]

如果你GLV（获取最新版本）一个解决方案，其中一些项目已更改，则VS会反复询问是否要重新加载每个更改的项目。关闭你的解决方案然后GLV，再打开解决方案比在打开解决方案时GLV快大约10倍。如果我正在GLV，当然我想重新加载项目！当我在超市购买食品时，他们不会问我“你想把这个东西带回家吗？”[编辑：在VS2010中仍然存在问题][在2012中修复了。万岁！]
[编辑] 如果两个团队成员向解决方案中添加了一个新项目，那么当第二个人去检入时，他们必须（显然）解决合并冲突。但是，TFS将.sln文件视为文本文件，并且会使其损坏（它会添加两个项目条目，但项目计数实际上只增加了一次）。修复sln格式以使文件可合并会非常容易。
[编辑] 我不会从解决方案资源管理器窗口执行任何源代码控制操作，因为自从“集成”出现以来，它一直不太可靠。即使在2008年，它通常在未检出的文件上随机显示“已检出”图标，递归操作有时会出现奇怪的情况。我们几乎每次遇到源代码控制的“故障”都是因为有人从解决方案资源管理器开始了一个操作。幸运的是，我更喜欢在源代码控制窗口中工作。[2012：很抱歉，我无法告诉您这是否已经修复，因为自2008年以来我就没有使用过此功能]
[编辑] 如何开始Source Control Bindings窗口？VS可以说“您的源代码控制设置又出了问题，原因不明。我从来没能掌握过星期四。我帮您修复一下，好吗？[是]”，但它却显示一个复杂、混乱的对话框，充满了对任何人都没有意义的信息，导致界面非常可怕，让初级程序员感到不安。诀窍是忽略整个窗口，躲在桌子后面，然后点击“修复”按钮，它就会修复。
[编辑-添加于2010年12月]当您获取源代码时，特别是在解决合并冲突时，通常会将其他窗口带到前面（解决方案资源管理器会跳到我停靠在同一个选项卡区域的挂起更改视图前面，或者源代码控制窗口会消失在另一个文档窗口后面）。当您有另一个文件要合并或另一个文件夹要获取时，这真的很烦人，因为您必须不断地“找到”源代码控制/挂起更改窗口。获取代码不应该不断重新排列我的文档/工具窗口。[2012：仍然存在问题]
[编辑-添加于2014年1月]使用TFS 2012/2013时，有一个服务器或本地工作区的选择。服务器是旧系统的名称，您必须在线与服务器连接才能检出文件。本地是新默认设置，由于您不再检查文件，因此在编辑文件时它们不会被锁定，因此多个人可以同时编辑任何给定的文件，在他们签入时需要进行合并操作。对于基于文本的源代码文件来说这是可以接受的，但当文件无法合并时会导致困难或丢失工作。无法合并或不自动合并的文件包括Solution、Project、Resource（resx）、XAML和任何其他XML文件 - 因此这在开发环境中会引起很多问题。如果（像我们一样）您还想将Word和Excel文档以及二进制文件存储在源代码控制下，则本地工作区非常危险。我们曾经因为某些人不知情地使用了本地工作区而丢失了几天的工作时间，然后无法合并他们的更改。您可以重新配置TFS服务器，使服务器工作区成为默认设置以防范此类情况。
使用本地工作区需要在计算机上保存两份副本。当我们升级TFS时，我们突然发现每个人都失去了25GB的磁盘空间，需要几周的时间才能找出磁盘空间去哪了！对我们来说，这是一个重大问题，因为我们都使用SSD，直到现在（2014年）SSD变得足够大/便宜，我们才能负担得起这种磁盘空间效率低下的做法。

在使用本地工作区的几周中，我们遇到了几起TFS损坏文件或丢失更改的事件，推测是由于实现中的错误所致。简而言之，我们不能接受源代码控制系统的可靠性低于100%。

TFS变得越来越易于管理；现在如果您不想太过定制化，您可以在很短的时间内（几个小时）设置一个服务器，并且设置持续集成构建和备份等非常容易。但与此相反的是，虽然我发现很容易设置TFS数据库的备份，但在我们的服务器崩溃后恢复该数据库并重新运行起来却是另一回事 - 它花了4天的时间来解决所有不必要的阻塞问题（例如，您必须从网络驱动器上还原备份，数据不能是本地的。当我试图将映像还原到重建的服务器时，TFS不断告诉我没有可以还原的数据库。当我克服了这个问题后，TFS不会使用这些数据库，因为它们与主机服务器不匹配（因为该服务器已经不存在了，操作系统已被重新安装）。花费了很多搜索和调整才能使备份恢复。恢复应该是“即插即用”的！

正如您所看到的，上述大部分只是微不足道的用户界面问题。有很多可以改进的地方。但实际的基础产品是不错的。在过去的28年中，我更喜欢TFS而不是其他大多数软件配置管理工具。
我并不介意糟糕的用户界面，但开发人员需要每时每刻使用它作为核心界面之一，并且他们必须支付大量费用才能使用它。如果来自单个开发人员的订阅费用被用于改进用户界面，它将极大地改善 TFS 的可用性！想到 TFS 只是“好的”或“还行”，而它可以很容易地成为“极好”的，这令人痛苦。