说服从CVS切换到SVN的参数

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

这个系统已经设置了很长时间，但现在，我有机会组织一次会议，在那里我必须提出修改建议。我想让它们从CVS变为SVN（Mercurial或Git可能更好，但我不能建议使用我不太熟悉的系统，而切换到SVN已经是一个很大的进步）

我对CVS没有太多的经验，因此无法有效地比较它们：我只知道它不支持原子操作，而且它已被弃用

你会用什么致命的论据来说服我的同事们做出改变

---

非常感谢。

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

---

我会开始在本地使用hg、git或其他DVC（致力于部门的CVS回购），以便您熟悉它们。由于其分布式特性，您可以开始自己实现这些好处，开始单独向同事展示这些好处，并最终在项目的实际经验支持下为转换提供有力的理由。

事实上，原子提交是一种破坏交易的功能，而不是一些美味的功能。例如，您希望提交50个已更改的文件。使用Svn您<代码> SvN提交，并且在提交过程中网络发生故障时，您的提交将被忽略。使用CVS，您将在存储库中有一半的提交，因此现在每个人都将更新到已损坏的代码，并变得不开心，日常构建可能会失败，使每个人更加不开心。使用svn，您要么成功提交，要么似乎从未想过提交—存储库始终保持完整。

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

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

无论如何，切换的参数：

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

---

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

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

我所从事的项目是一个开源Java应用程序，它刚刚起步，规模不断扩大，所以所有东西都在包“core.*”中。当重新考虑因素并将内容放入一个好的包层次结构时。。。CVS重置了所有的版本信息，因为据它所知，我们刚刚删除了整个“core/”文件夹，并凭空创建了一堆新文件

---

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

我否决了你。使用hg或git以及CVS是完全没有意义的。如果他想练习，就在家里练习。@silky：我想所有那些编写工具在其他回购协议（如hgsvn）之上分层DVC的人都是在浪费时间。@Roger这是一个多么荒谬的评论啊。我不会再和你讨论这个问题了，因为这肯定是徒劳的。我只是在解释否决票。事实上，我就是这么做的：我在家里练习，但即使我认识到新版本控制系统的好处，SVN也更有可能被采用，因为它与CVS相似。理想情况下，我会使用Git或Mercurial，但这不是一个选项。我不认为他们会失败：他们只是不是最新的，也不知道什么是新的解决方案。1投票赞成：我们使用的CVS和Mercurial几乎完全符合Roger描述的方式。使用CVS的理由还是比较充分的，但是Mercurial提供了太多的附加值，所以不忽略它是愚蠢的。。。交易破坏者是。。。到底是什么？不知道这意味着什么；）@ereOn：他的意思是，CVS中没有原子提交本身就足以成为避免CVS的理由。你显然是对的：我的第一个目标应该是解决现有的问题。事实上，整个体系结构是一团糟，但似乎有些人只是说“可能更糟”，而我想说“可能更好”。人们经历问题并不罕见，但没有意识到它们是问题，反而认为事情本来就是这样。谢谢你的论点。我的会议将在下周举行：试图推荐一家我不精通的风投公司不是有点冒险吗？（Mercurial）在那之前我显然学不好。。。或者我可以？这么快有点冒险，你说得对。但是您应该仔细研究一下，因为存储库设置听起来像Mercurial.Tool