用于 Java 的 TFS - 坏主意？答案

【问题标题】：TFS for Java - bad idea?用于 Java 的 TFS - 坏主意？
【发布时间】：2017-04-03 23:31:59
【问题描述】：

我们正在考虑将 TFS 用于我们基于 .NET 的项目并将其作为任务管理平台。一些团队专门使用 Java 进行开发，他们对 SVN (Subclipse) 非常满意。

我们的经理提出了以下问题：

我们是否也应该将 Java 团队迁移到 TFS？
TFS（仅限源代码控制）能否很好地处理 Java 项目？
将我们的 Java 代码库和历史从 Subclipse 迁移到 TFS 是否很痛苦？

目前，出于可维护性的原因，我们正在寻求使用 TFS 作为唯一的源代码控制平台。我们希望避免让我们的 IT 人员支持多个系统。

谢谢

【问题讨论】：

您的 Java 开发人员使用什么 IDE？ Microsoft 为 Eclipse 提供了一个用于 TFS 的插件。有一个免费的演示可供下载，以便您的 Java 开发人员可以查看它。 microsoft.com/visualstudio/en-us/products/2010-editions/…
他们使用 Eclipse。感谢您的链接。我会检查一下。
考虑到你在一年前问过这个问题，我想知道你是否有跟进？
@DustyJ 我又添加了一个答案——和你有同样的经历
迁移到 TFS 已经 2 年了。刚升级到2013。团队绝对喜欢它，甚至想不起过去的svn时代！

标签： java svn tfs subclipse

【解决方案1】：

完全披露，我在为 TFS 编写 Java 工具的团队工作，因此请将此答案视为适当的偏见 :-)

就 TFS 而言 - 所有代码都是平等的。它只是检查到版本控制的文件中的字节。像所有 SCM 系统一样，它并不关心文件是用什么语言编写的。

Microsoft 提供了一个完整、丰富的TFS Plug-in for Eclipse（称为 Team Explorer Everywhere）。这提供了从基于 Eclipse 的 IDE 到 TFS 的完整源代码控制、工作项跟踪、构建、共享点、报告访问等。它是 100% 用 Java 编写的，直接与 TFS 公开的 Web 服务对话。

此外，我们还提供cross-platform command line client for TFS，以便您可以在您选择的操作系统（Mac、Linux、Solaris、HP-UX、Aix 等都完全支持）上通过命令行与 TFS 对话。

最后，如果您有用 Java 编写的工具想要与 TFS 通信，那么他们可以使用 TFS SDK for Java，这是我们用来创建 Eclipse 集成和跨平台命令行客户端但已打包的完整 API提供示例和 sn-ps，并准备好与您的应用程序一起重新分发。

在构建方面，您有多种选择。如果您想坚持使用当前的构建服务器，那么它很可能已经支持与 TFS 通信（所有流行的开源构建服务器都支持）。除此之外，Microsoft 提供了TFS Build Extensions，它允许您在 Team Foundation Build 服务器上运行基于 Ant 或 Maven 的构建。如果您在构建过程中执行 JUnit 测试，构建结果（连同任何警告或错误）将连同任何 JUnit 测试数据一起发布回 TFS。您还可以在 Eclipse IDE 中创建和管理构建定义，并在一个地方管理对它们的访问等。

所以 - 对 Java 的支持水平非常高，微软在这一领域表现出持续的投资。我们最近发布了一些 TFS 2010 Power Tools for Eclipse，我们还发布了 Team Explorer Everywhere 11 和 Team Foundation Server 11 的预览版（我们是公司内部的同一个团队）。

要从 SVN 导入历史记录，这与将历史记录从任何 SCM 工具导入 TFS（或将 TFS 导入任何 SCM 工具）相同。你有几个选择。您可以拍摄快照并在特定时间点（例如发布）切换，也可以迁移历史记录。要从 SVN 迁移历史，有一些可用的合作伙伴解决方案，包括来自 Timely Migration 的一个解决方案，我已经看到很多客户都成功了。

希望对您有所帮助。

【讨论】：

马丁，这很有帮助。谢谢！

【解决方案2】：

在使用 TFS 从事 Java/JVM 项目一年后，我想劝阻任何人不要这样做。虽然 TFS 可能被认为是 .NET 开发人员的顶级产品，但您不会找到任何具有这方面经验的 Java 开发人员。有 Eclipse 的插件和 IntelliJ 的端口，但我在这两个方面的运气都很糟糕，虽然我猜这主要是因为 TFS 不像我使用的任何其他 VCS 那样工作。

在我们的团队中，我们估计 TFS 和由此引起的并发症会产生 10-15% 的开销。因 TFS 决定覆盖文件而浪费了数天的工作时间，因 TFS 更新不完整而导致的问题故障排除了数天。我们在 6 个月内完成了一个分支，因为我们上次这样做时整个团队损失了两天。经常听到这样的短语“我刚刚更新了您的最新更改，您能来检查以确保合并中没有任何内容消失吗？”。我们没有使用 Jira，而是使用 TFS 中糟糕的问题跟踪，导致更多问题。

团队中的一些开发人员已经开始使用 git，无论是独立的还是 git-tfs 桥。其他人只是在任何“有风险”的活动（例如更新或签入）之前复制源代码树。

无论如何，我不会向没有经验的团队推荐它......

【讨论】：

QFT。我们遇到过多种情况，其中 TFS（或 Eclipse 插件，谁知道）只是没有将所有内容提交到存储库。客户端声称每个更改都已提交，而在服务器上则不存在。对于 VCS 来说，这是相当令人担忧的行为。还;祝你好运重命名你的包结构，TFS 不断告诉你“此时 Team Foundation Server 无法删除重命名后剩余的空包。”。 TFS 和 Eclipse 插件本身并不坏，只是它们运行得不够好，我无法推荐它。
这个答案还有效吗？我想知道，因为 TFS 现在支持 Git。
我不再使用 TFS，但我怀疑 Microsoft 是否在第一次尝试时获得了正确的 Git 仿真...
TFS 根本不“模拟” Git。它只是使用普通的旧 msysGit。到 2017 年，我认为 Git 已经取代 TFSVC 作为 TFS 的主要 VCS。
FWIW，TFS 不是/从来不是“.NET 开发人员”的“顶级”。开发者就是开发者，TFS/TFVC 是一种可怕的体验。现在，我一直在等待大约 5 分钟，以便在获取最新版本后打开合并窗口。在此之前，我在获取最新版本时弹出了大约 20 个错误对话框。这是正常。各位，请使用 Git 而不是 TFS/TFVC。请！

【解决方案3】：

我非常喜欢@Martin_Woodward 的回答，但在我看来它太有偏见了，所以我在这里加上我的 2 美分。我们公司的情况类似，决定（在我看来）取决于具体情况。我可以看到 3 种不同的情况，每种情况的决定可能不同：

您主要开发 .NET 解决方案，而 Java 部分已集成在 .NET 解决方案中。
您的 .NET 解决方案是独立于 Java 解决方案开发的，它们一半是 .NET，一半是 Java。
您的大多数解决方案都是使用 Java 开发的，只有一小部分是使用 .NET 开发的

我只同意马丁的第一种情况。您将从通用开发环境、源代码控制、构建过程中获益……您的 Java 人员将了解 TFS 源代码控制的不同之处（它有名字吗？？）。你的未来会很光明;-)

如果您的 .NET 解决方案和 Java 解决方案彼此独立，那么使用 TFS 开发 Java 解决方案的唯一理由是运营成本。您应该仔细考虑一下，如果仅运行 TFS 的开发环境所节省的成本会超过将您的 Subversion 项目切换到 TFS 的额外成本。

在最后一种情况下，为了有一个共同的开发环境而与很多人切换将是一个糟糕的决定。您可以将 Subversion 集成到 VisualStudio 中（使用例如 VisualSVN 或其他插件），您几乎没有任何投资。

包含历史的源代码的迁移通常是一件痛苦的事情，并且它是否运作良好取决于源代码和目标。我们在 CSV 和 SVN 方面有很好的经验，但在其他方面没有（好的）经验。但这通常不是问题，您可以使用旧的 SVN 存储库（只读）并迁移最后一个里程碑。一段时间后，SVN repos 可能就更不用说了......

【讨论】：

这个答案中遗漏的重要一点是，TFS 添加的不仅仅是源代码控制。 Team Explorer Everywhere 还添加了工作项管理、基本问题跟踪和跨项目报告功能。仅 SVN 无法提供的东西。我不得不承认，有一些开源工具结合起来提供了类似的功能集，但据我所知，没有一个工具可以为 Java 和 .NET 开发提供像 TFS 这样广泛的功能集。

【解决方案4】：

在使用 TFS/Java 工作了 1 年后，我完全同意 Dusty J（是的，TFS/Java 很糟糕）并且完全不同意 Martin Woodward 对微软的大力支持。虽然对于我作为开发人员的职责而言，Eclipse TFS 是可以的，但问题在于我的构建/发布职责。

首先，这个 Eclipse 插件不允许像在 CVS/SVN 中那样一次为多个项目创建一个分支。需要为每个项目单独创建一个分支。然后我们不能在分支中保留相同的项目名称 - 需要更改项目名称并在从分支中签出后重命名为原始名称。另请参阅我的帖子How to associate an Eclipse Workspace with TFS workspace?，无法将 Eclipse 工作区与 TFS 工作区相关联。因此，无法保存本地文件夹的映射；打开另一个 Eclipse 工作区以进行分支构建后，需要再次执行此操作。并且由于本地映射是相同的，因此有可能像 Dusty J 所写的那样擦除带有未保存工作的本地文件夹。

这种在没有警告的情况下删除本地文件是 TFS 的一个可怕特性（参见帖子 Why command get from a command line in TFS removes parallel projects?）。 对于在 Eclipse 中的常规选项“删除本地映射”下擦除本地文件的可能性，Microsoft 有何看法？

因此，尽管我努力学习 TFS，但与以前使用的 CVS 相比，我在各种构建上花费的时间仍然多 10 倍。

【讨论】：

很抱歉让您感到沮丧，但我并不完全符合您的要求。当然，您应该能够一次分支多个项目。您在这里或在 MSDN 论坛上问过问题吗？ social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=tee
为什么你确定 Eclipse 插件可以做到这一点？我试了很多次
我们在 Teamprise 2.0 中添加了分支功能，并对其进行了广泛的测试；我们允许您分支一个非常复杂的工作区映射。因此，我们很想更好地了解您的工作流程，以了解为什么该插件不适合您。
我需要一个新的 Eclipse 插件吗，我现在有 12.0.0.201310110941？谢谢
不，那个版本是合法的。我认为有一个更新的版本，但它会有新的功能，没有什么能解决你的抱怨。真的，虽然：我很抱歉你一年不开心。如果您提出一个新问题，其中概述了您想要什么以及您正在采取的步骤，我们会尽力帮助您。

【解决方案5】：

（另一位有偏见的 MS 员工）

TFS 大约在 18 个月前组建了一个团队，专注于在 TFS/Team Services 和所有平台上打造出色的 Java 体验。我在那个团队中，我认为我们已经取得了很大的进步。当被问到这个问题时，我不同意端到端的故事非常糟糕，但我认为答案在去年发生了很大变化。

我的团队为 TFS 以及 Eclipse 和 IntelliJ 插件提供构建和部署任务，以使端到端体验尽可能完整。如果您是 Java 开发人员，我们也在努力确保记录如何充分利用 TFS。

如果您想了解更多详情，请查看http://java.visualstudio.com。

谢谢，杰森·普里克特

【讨论】：

【解决方案6】：

为什么不将 SVN 用于 .NET 项目？有什么理由吗？ Visual Studio 中的 SVN 有多个 plugins 以及一个 windows shell extension。

【讨论】：

感谢亚历克斯的回答。我们的 .NET 团队喜欢 TFS 的项目管理和错误跟踪功能的主要原因。在 ALM 前景中，它使我们对项目进度有更多的控制和展望。第二个原因是我们的 Java 项目是较旧的遗留项目，我们知道有一天我们将成为 100% .NET。我们有一个团队正在将 Java 移植到 .NET...
有包括 Subversion 的开放 ALM 平台，例如 CollabNet TeamForge - open.collab.net/products/ctf。这包括用于问题跟踪器和 Subversion 的 Visual Studio 和 Eclipse 客户端。如果您将来需要，还包括对 Git 的支持。
是的，如果高昂的投资成本不是问题，Microsoft 工具通常是非常强大的工具，并且正如您从 Martin 的回答中看到的那样，有很多很好的解决方案可以解决您的问题。告诉我们迁移将如何进行，祝你好运！