我同意 Keith Thompson 关于继续使用 CVS 的说法,但是,基于通过实际尝试 git 两周完成的对 DVCS 的审查,我不能推荐 git 作为经验丰富的 cvs 用户的平滑替代品,他们希望以最少的速度平稳过渡到 DVCS再培训。重新阅读最后一句,同时特别注意限定条款。我并不是说 git 有能力成为一个优秀的工具。虽然个人经验通常是非常主观的,但 git 在确定使用两周后从未“感觉到”,以便学习它作为 CVS 的潜在替代品。在尝试它的过程中,我设法把事情(想想存储库)搞砸了好几次,有些事情我从来没有迅速弄清楚。
当我碰到 git 无法对目录进行版本控制的墙时,我将 Mercurial 和 Bazaar 视为最有可能考虑的候选者,并发现 Mercurial 与 git 有相同的问题。在 CVS 中,我可以轻松地添加包含现有文件的目录,而无需在其中添加文件。git 和 Mercurial 似乎这样做是一件荒谬的事情。该工具要求我无法在各种用例中做有意义的事情,这让我很困扰。结果,我尝试了 Bazaar,令人惊讶的是,我在几分钟内就感到很舒服。使用 git 两周后,我从来没有这样做过。我的 git 存储库在几分钟内转换为 Bazaar,并且我在不到一个小时的时间内就可以轻松使用它。
我目前仍在使用 CVS,尽管我已承诺使用 Bazaar,但我在一些边缘情况下遇到了烦恼,我在应用程序中使用 Bazaar,而这些应用程序在软件开发中通常不是问题。即便如此,作为最有可能在替代 VCS 中培训一组 CVS 同事的人,我坚信 Bazaar 将需要最少的再培训。在与 CVS 工作流程密切相关的工作流程中使用 Bazaar 几乎是微不足道的。与我一起工作的人不会通过版本控制来获得乐趣。他们想要一些不引人注目且易于学习的东西。我知道,如果他们发现学习曲线最令人生畏,他们就不会最大限度地利用 VCS。
选择 Bazaar 的重要之处在于它可以轻松地在 Windows 上运行,并与 MinGW MSYS 环境很好地集成。集成的 Windows 安装程序非常适合希望以统一方式最小化设置工作站的工作的环境 - 特别是在一些用户需要命令行工具而其他用户需要图形工具的情况下。
VCS 的选择通常会受到各种偏见的影响。我开始寻找 DVCS,而不会对任何特定工具产生偏见。我发现 git 天生就有偏见。它是在对 CVS 的强烈仇恨(参见作者对 CVS 的态度)和 CVS 之类的东西 $Id: $ 的情况下开发的。Bazaar 声称它试图避免对各种工作流程的偏见,并且似乎避免对开发人员在他们对其他 VCS 的特定使用中开始欣赏的事物采取立场。诚然,这是一个主观的说法,但我在 Bazaar 的经验似乎表明这是真的。
Bazaar 没有提供我想要的一切。例如,我不高兴它不支持部分结帐。这在 CVS 中非常容易做到。我对 Bazaar 操作完全因文件访问问题而失败而感到恼火,因为一组文件中的单个文件正在被操作,但这通常不应该发生在典型的软件开发用例中。我想说的是,我并没有盲目地迷恋 Bazaar,但我仍然相信它是小型工程部门从 CVS 过渡到最简单的工具。
作为一个脚注,多年前加入了一个 SVN 开源开发团队,其明确目标是适应类似 CVS 的改进 VCS。我与 SVN 合作了很多,甚至设置了部分结帐等,但我不同意 SVN 是“CVS 做得对”。经过多年的使用,由于多种原因,我无法负责任地选择 SVN 作为我组织中 CVS 的继任者。它将一组问题换成另一组问题。虽然这对于几乎所有工具都是如此,但在考虑过渡成本时,SVN 的好处似乎并没有超过问题。