3

我工作的团队仍然使用SUN Teamware进行源代码管理 (SCM)。我已经使用它一段时间了（超过 10 个月），我对它没有任何特别的抱怨。

Teamware 已被用于管理 Sun 最大的源代码树，包括用于 Solaris 操作系统和 Java 系统的源代码树，并且运行良好。但它也是一个已经停产的旧商业（闭源）产品。这是 Sun 将其代码库转换为开源社区的过程的一部分，这反过来又导致转向更新的版本控制系统，例如 Mercurial。

这让我感觉有点像我们在使用 Teamware 时陷入了困境，而世界已经转向更新的系统。然而，我并没有错过任何特定的功能，除了可能有一个源树的 Web 视图来浏览和查看文件的历史记录（我们用 VersionTool 做的事情并不重要）。

使用 SUN Teamware 的团队是否应该迁移到更现代的 SCM，例如 git 或 Mercurial？

更重要的是，你可以向团队的其他成员提出什么论据来支持这种转变？

4

3 回答 3

2

您是否看到 Sun 所做的评估：

  • git（注意他们评估了一个旧的 1.2.4 版本。要点：FAST），
  • Mercurial (), 和
  • 市场

作为 Solaris 代码库替换 Sun Teamware VCS 的候选者？

在考虑迁移时，这可能会提供一些关于要评估的主题的想法。

此Git 调查 2007-2008中列出了其他一些主题。

于 2009-02-18T16:38:16.113 回答
2

我是 SCM 的忠实粉丝，但我不得不说，如果它没有坏，就不要修复它。在 Teamware 不再满足您的需求之前，请继续使用它。

于 2009-02-18T16:11:29.813 回答
0

在字里行间，我想即使你也没有真正的论据，除了当前趋势留下的个人感觉。不幸的是，这并不是将大型代码库从一个 SCM 迁移到另一个的论据。

我想保持最新，你仍然可以在家里玩 git/Mercurial/Bazaar。

于 2009-02-18T16:38:05.523 回答