TFS for Java – 糟糕的主意？
我们正在考虑将TFS用于基于.NET的项目和任务管理平台。 有些团队只使用Java开发，他们对SVN（Subclipse）非常满意。
我们的经理提出了以下问题：
- 我们是否应该将Java团队迁移到TFS？
- TFS（仅限源代码控制）是否处理好Java项目？
- 将我们的Java代码库和历史从Subclipse迁移到TFS是一件痛苦的事吗？
目前，出于可维护性原因，我们希望将TFS用作唯一的源控制平台。 我们希望避免让我们的IT人员支持多个系统。
谢谢
完全披露，我在为TFS编写Java工具的团队工作，所以把这个答案视为适当的偏见:-)
就TFS而言 – 所有代码都是相同的。 它只是文件中的字节，它检入版本控制。 像所有SCM系统一样，它不关心文件的编写语言。
Microsoft 为Eclipse提供了一个完整，丰富的TFS插件 （称为Team Explorer Everywhere）。 这为基于Eclipse的IDE提供了完整的源代码控制，工作项跟踪，构建，共享点，报告访问等。 它是用100％Java编写的，直接与TFS公开的Web服务进行对话。
此外，我们还为TFS提供了一个跨平台的命令行客户端，以便您可以从所选操作系统（Mac，Linux，Solaris，HP-UX，Aix等全部支持的命令行）的命令行与TFS对话。
最后，如果您使用Java编写的工具想要与TFS交谈，那么他们可以使用TFS SDK for Java ，它是我们用于创建Eclipse集成和跨平台命令行客户端的完整API，但打包了样本和代码段，随时可以使用您的应用程序重新分发。
在构建时，您有几个选择。 如果您想坚持使用当前的构建服务器，那么很可能这已经支持与TFS（所有流行的开源构建服务器都可以）进行通信。 除此之外，Microsoft还提供了TFS Build Extensions ，它允许您在Team Foundation Build服务器上运行基于Ant或Maven的构建。 如果您在构建过程中执行JUnit测试，则构建结果（以及任何警告或错误）将与任何JUnit测试数据一起发布回TFS。 您还可以在Eclipse IDE中创建和管理构建定义，并有一个位置来管理对它们的访问等。
所以 – 对Java的支持程度非常高，微软已经在这方面进行了持续的投资。 我们最近发布了一些用于Eclipse的TFS 2010 Power Tools ，我们还一直在发布Team Explorer Everywhere 11的预览版本以及Team Foundation Server 11（我们是公司内部的同一个团队）。
要从SVN导入历史记录，这与将历史记录从任何SCM工具导入TFS（或将TFS导入任何SCM工具）相同。 你有几个选择。 您可以拍摄快照并在特定点（例如发布）切换，也可以迁移历史记录。 要从SVN迁移历史记录，可以使用一些合作伙伴解决方案，包括Timely Migration中的一个，我见过许多客户都取得了成功。
希望有所帮助。
在使用TFS开发Java / JVM项目一年后，我想劝阻任何人这样做。 虽然TFS可能被认为是.NET开发人员的首选，但您将找不到任何具有任何经验的Java开发人员。 有Eclipse的插件和IntelliJ的端口，但我两个都运气不好，虽然我猜它主要是因为TFS不像我用过的任何其他VCS那样工作。
在我们的团队中，我们估计由于TFS和由此引起的并发症导致10-15％的开销。 由于TFS决定覆盖文件，因为TFS更新不完整而导致数天的故障排除问题。 我们在6个月内完成了一个分支机构，因为整个团队最后一次丢失了两天。 通常会听到“我刚刚更新了您的最新更改，您可以检查以确保合并中没有任何消失吗？”。 我们不再使用Jira，而是在TFS中使用可怕的问题跟踪，导致更多问题。
团队中的一些开发人员已经采用了独立或git-tfs桥接器的git。 其他人只是在任何“冒险”活动之前复制源树，例如更新或签入。
无论哪种方式，我都不会推荐给没有经验的团队……
我非常喜欢@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回购可能更不用说……
使用TFS / Java一年后，我完全赞同Dusty J（是的，TFS / Java很糟糕），并且完全不同意Martin Woodward关于微软的支持。 虽然我作为开发人员的职责是Eclipse TFS没问题，但问题在于我的构建/发布职责。
首先，这个Eclipse插件不允许像CVS / SVN一样为多个项目创建分支。 人们需要为每个项目单独创建一个分支。 然后我们不能在分支中保留相同的项目名称 – 一个需要更改项目名称，并在从分支签出后重命名为原始名称。 另请参阅我的文章如何将Eclipse Workspace与TFS工作区相关联？ ，无法将Eclipse工作区与TFS工作区相关联。 因此，无法保存本地文件夹的映射; 在为分支构建打开另一个Eclipse工作区之后，需要再次完成它。 由于本地映射是相同的，因此可能会像Dusty J写的那样用未保存的工作擦除本地文件夹。
这种删除本地文件而不发出警告是TFS的一个可怕特性（请参阅post为什么命令从TFS中的命令行获取并删除并行项目？ ）。 微软认为在Eclipse中常规选项“删除本地映射”下删除本地文件的可能性是什么？
因此，尽管我努力学习TFS，但与之前使用的CVS相比，我仍然花费10倍于各种构建的时间。
（另一位有偏见的MS员工）
大约18个月前，TFS成立了一个团队，专注于在TFS /团队服务和所有平台上实现卓越的Java体验。 我在那个团队中，我认为我们取得了很大的进步。 当问到这个问题时，我不会不同意端到端的故事是非常糟糕的，但我认为答案在去年有所改变。
我的团队为TFS以及Eclipse和IntelliJ的插件提供构建和部署任务，以使端到端体验尽可能完整。 我们也在努力确保如果您是Java开发人员，我们会记录如何充分利用TFS。
如果您想了解更多详情，请访问http://java.visualstudio.com 。
谢谢，杰森普里克特
为什么不将SVN用于.NET项目？ 有什么理由吗？ Visual Studio中有多个SVN 插件以及Windows shell 扩展 。