说服从CVS切换到SVN的参数

Question

我公司的UNIX部门目前使用 CVS 作为源版控制系统。他们以非常奇怪的方式使用它：开发/测试/生产代码的不同存储库（对于同一个项目），没有人标记任何东西，奇怪的目录架构等等。

该系统已经设置了很长时间，但现在，我有机会组织一次会议，我必须建议更改。我想让他们从 CVS 更改为 SVN （Mercurial或Git可能会更好，但我不能真正推荐使用我不知道的系统好吧，切换到SVN已经是向前迈出的一大步了。）

我对CVS没有多少经验，所以我无法有效地比较它们：我只知道它不支持原子操作并且已弃用

你会用什么杀手参数来说服我的同事进行转换？

非常感谢。

Answer 1

嗯，这个设置听起来像是一个分布式VCS，因此Mercurial或Git可能会非常匹配。多存储库设置是它的特色。我个人更喜欢Subversion，但在你的情况下你应该看看这些，hginit可能是对Mercurial的一个很好的介绍。

无论如何，切换的论点：

• 原子提交
• 更好地处理二进制文件
• 目录的版本控制（仅限SVN）
• 文件和目录的属性（仅限SVN）

Answer 2

实际上，原子提交是一个交易破坏者，而不是一些美味的功能。例如，您要提交50个已更改的文件。对于SVN，您svn commit并且发生网络在提交过程中失败 - 您的提交将被忽略。使用CVS，您将拥有存储库中一半的提交，因此现在每个人都会更新到破坏的代码并变得不快乐，每日构建可能会失败并使每个人更加不快乐。使用svn，您可以成功提交，或者看起来您从未提交过 - 存储库始终保持不变。

Answer 3

说实话，如果你必须努力说服他们，那么他们可能会期望它失败（即使只是下意识地），你的努力可能会更好地花在其他地方。

我开始在本地使用hg，git或其他DVCS（承诺部门的CVS回购），这样你就可以熟悉它们了。由于它们的分布式特性，您可以自己开始实现这些好处，开始向同事单独展示的好处，并最终为您的项目中的实际经验提供强大的转换支持。

Answer 4

问题是 - 当前的CVS设置遇到了哪些具体问题？你改变的原因应该解决这些问题。但如果他们没有遇到任何问题，为了改变而改变并不是一个好主意 - CVS实际上会在很多情况下完成工作。如果他们是老式的UNIX人员，他们可能会记得过去一些真正可怕的版本控制系统，并认为CVS非常整洁！

Answer 5

文件重命名/移动！单独考虑，我怀疑这是一个令人信服的理由转换，但它确实对我所参与的项目产生了严重影响。

请参阅，CVS不允许您重命名/移动文件。如果您重命名或移动文件，CVS会认为旧一个消失，并且 new 一个出现，并且它们之间没有连接。虽然没有真正的丢失修订历史记录，但如果您在某个特定日期之前返回，则必须知道“文件X”实际上是“文件Y”。哦，版本号都被重置了。

我正在开发的项目是一个开源的Java应用程序，它刚刚起步很小并且不断发展壮大，因此所有内容都只是在“核心。*”中。当时间重新考虑并将内容放入一个漂亮的包层次结构中......好吧，CVS重置所有版本信息，因为，就它知道，我们刚刚删除了整个“核心/“文件夹，并凭空创造了一堆新文件。

据推测，SVN 意识到正在移动/重命名的文件，因此它不会破坏版本沿袭。不知道Git是否这样做。