说服从 CVS 切换到 SVN 的论据答案

【问题标题】：Arguments to convince to switch from CVS to SVN说服从 CVS 切换到 SVN 的论据
【发布时间】：2010-04-13 09:09:36
【问题描述】：

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

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

我在 CVS 方面没有太多经验，因此无法有效地比较它们：我只知道它不支持原子操作并且它已不推荐使用 .

你会用什么killer论据来说服我的同事进行转换？

非常感谢。

【问题讨论】：

标签： svn version-control cvs

【解决方案1】：

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

无论如何，切换参数：

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

【讨论】：

感谢您的论点。我的会议将在下周举行：尝试推荐一个我不掌握的 VCS 是不是有点冒险？（Mercurial）我显然不能在那之前学好它......或者我可以吗？
这么快有点冒险，你是对的。但你应该调查一下，因为存储库设置听起来像 Mercurial。
工具支持是 SVN 的其他优势之一。您不必选择一个客户端，但您可以决定哪个客户端最适合哪种场景：TortoiseSVN、命令行、AnkhSVN、VisualSVN、Subclipse 等都使用相同的库，因此是磁盘格式，因此您可以在它们之间切换随时随地。

【解决方案2】：

实际上原子提交是一个交易破坏者，而不是一些美味的功能。例如，您要提交 50 个已更改的文件。使用 SVN，您 svn commit 会在提交过程中发生网络故障 - 您的提交将被忽略。使用 CVS，您将在存储库中拥有一半的提交，所以现在每个人都会更新到损坏的代码并变得不开心，而日常构建可能会失败，让每个人都更加不开心。使用 svn，您要么成功提交，要么看起来好像从未考虑过提交 - 存储库始终完好无损。

【讨论】：

对不起，我的英语不是母语，但是...破坏交易是...到底是什么？不知道这意味着什么;）
@ereOn：他的意思是，在 CVS 中没有原子提交本身就足以成为避免 CVS 的理由。

【解决方案3】：

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

我会开始在本地使用 hg、git 或其他 DVCS（提交到部门的 CVS 存储库），以便您熟悉它们。由于它们的分布式特性，您可以开始自己实现收益，开始向同事单独展示收益，并最终在项目中的真实经验支持下为转换提供强有力的理由。

【讨论】：

我对你投了反对票。使用 hg 或 git 以及 CVS 绝对没有意义。如果他想练习，请在家练习。
@silky：我猜所有那些编写工具以将 DVCS 放在其他存储库（例如 hgsvn）之上的人只是在浪费时间。
@Roger 多么荒谬的评论。我不会再和你讨论这个了，因为它肯定是没有结果的。我只是在解释否决票。
其实我就是这么干的：我在家里练习，但即使我认识到更新版本控制系统的好处，SVN也更有可能被采用，因为它与 CVS 的相似之处。理想情况下，我会 impose Git 或 Mercurial，但这不是一个选择。我不认为他们会失败：他们只是不是最新的，也不知道什么是更新的解决方案。
1 票赞成：我们使用 CVS 和 Mercurial 的方式几乎与 Roger 描述的完全一样。使用 CVS 仍有相对充分的理由，但 Mercurial 提供了如此多的附加值，不忽略它是愚蠢的。

【解决方案4】：

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

【讨论】：

您显然是对的：我的首要目标应该是解决现有问题。实际上整个架构是一团糟，但似乎有些人只是说“可能会更糟”，而我想说“可能会更好”。
人们遇到问题并不罕见，但没有意识到他们是问题，反而认为事情本来就是这样。

【解决方案5】：

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

看，CVS 不允许您重命名/移动文件。如果您重命名或移动文件，CVS 会认为 old 文件消失了，而 new 文件出现了，它们之间没有任何联系。虽然没有真正丢失修订历史，但如果你在某个特定日期之前返回，你必须知道“文件 X”实际上是“文件 Y”。哦，版本号都被重置了。

我正在从事的项目是一个开源 Java 应用程序，它刚开始很小，并且不断发展壮大，所以一切都在“core.*”包中。当需要重构并将东西放入一个漂亮的包层次结构中时......好吧，CVS 重置了所有版本信息，因为据它知道，我们刚刚删除了整个“ core/" 文件夹并凭空创建了一堆新文件。

据说，SVN 知道文件被移动/重命名，所以它不会破坏版本沿袭。不知道 Git 是否这样做。

【讨论】：