说服从 CVS 切换到 SVN 的论据
我公司的UNIX部门目前使用CVS作为源版本控制系统。他们以一种非常奇怪的方式使用它：用于开发/测试/生产代码的不同存储库（对于同一项目），没有人标记任何内容，奇怪的目录架构等等。
该系统已经设置了很长时间，但现在，我有机会组织一次会议，我必须在会上提出更改建议。我想让它们从 CVS 更改为 SVN （Mercurial 或 Git 可能更好，但我真的不能推荐使用我不知道的系统好吧，切换到 SVN 已经是向前迈出的一大步了）。
我对 CVS 没有太多经验，因此无法有效地比较它们：我只知道它不支持原子操作并且它已弃用。
您会用什么杀手锏来说服我的同事进行转变？
非常感谢。
The UNIX department of my company currently uses CVS as source-version control system. They use it in a very strange way: different repositories for development/testing/production code (for the same project), no one tags anything, weird directory architecture, and so on.
The system has been set for ages but now, I have an opportunity to organize a meeting where I have to suggest changes. I'd like to make them change from CVS to SVN (Mercurial or Git might be even better, however I can't really recommand using a system I don't know well, and switching to SVN will already be a great step forward).
I don't have much experience with CVS so I can't compare them efficiently: I just know it doesn't support atomic operations and that it is deprecated.
What killer arguments would you use to convince my collegues to do the switch ?
Thank you very much.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
嗯，这个设置听起来像分布式 VCS，因此 Mercurial 或 Git 可能会很好地匹配。多存储库设置是它的特色。我个人更喜欢 Subversion，但就你的情况而言，你应该看看这些，hginit 可能是 Mercurial 的一个很好的介绍。
无论如何，切换的参数：
Hmm, this setup sounds like a distributed VCS, so Mercurial or Git may match in very well. Multi-repository-setup is the speciality of it. I personally prefer Subversion, but in your case you should take a look at these, hginit may be a good introduction to Mercurial.
Anyways, arguments for switching:
实际上原子提交是一个交易破坏者，而不是一些美味的功能。例如，您想要提交 50 个更改的文件。使用 SVN，您
svn commit，并且在提交过程中网络发生故障 - 您的提交将被忽略。使用 CVS，您将在存储库中拥有一半的提交，因此现在每个人都会更新到损坏的代码并变得不高兴，并且每日构建可能会失败并使每个人更加不高兴。使用 svn，您要么成功提交，要么看起来像您从未想到过提交 - 存储库始终完好无损。Actually atomic commits are a deal breaker, not some tasty feature. For example, you want to commit 50 changed files. With SVN you
svn commitand it happens that network fails in the middle of commit - your commit will be ignored. With CVS you will have a half of the commit in the repository, so now everyone will update to broken code and become unhappy and the daily build can fail and make everyone even more unhappy. With svn you either have a successful commit, or it looks like you have never though of the commit - the repository is always intact.老实说，如果你必须努力说服他们，那么他们可能会认为它会失败（即使只是潜意识的），而你的努力可能会更好地花在其他地方。
我会开始在本地使用 hg、git 或其他 DVCS（致力于部门的 CVS 存储库），以便您可以熟悉它们。由于它们的分布式特性，您可以开始自己实现这些好处，开始向同事单独展示这些好处，并最终在项目中的真实经验的支持下提出强有力的转换案例。
To be honest, if you have to work hard to convince them, then they'll likely be expecting it to fail (even if only subconsciously) and your effort might be better spent elsewhere.
I'd start using hg, git, or another DVCS locally (committing to the department's CVS repos) so you can get familiar with them. Due to their distributed nature, you can start realizing the benefits yourself, start showing the benefits to colleagues individually, and eventually make a strong case for conversion backed by real experience within your projects.
问题是 - 当前的 CVS 设置遇到了哪些具体问题？您改变的原因应该解决这些问题。但如果他们没有遇到任何问题，为了改变而改变并不是一个好主意 - CVS 实际上在很多情况下都能完成这项工作。如果他们是老 UNIX 爱好者，他们可能还记得过去一些真正可怕的版本控制系统，并认为 CVS 非常简洁！
The question is - what specific problems are being experienced with the current CVS setup? Your reasons for change should address those. But if they are not experiencing any problems, change for change sake is not a good idea - CVS actually will do the job in a lot of cases. And if they are old-time UNIX guys, they probably remember some of the truly horrid version control systems from the past, and think that CVS is quite neat!
文件重命名/移动！单独来看，我怀疑这是一个令人信服的转换理由，但它确实对我曾经参与的一个项目产生了严重影响。
看，CVS 不允许您重命名/移动文件。如果您重命名或移动文件，CVS 会认为旧文件消失，新文件出现，并且它们之间没有任何联系。虽然修订历史记录并没有真正丢失，但如果您在某个特定日期之前返回，您必须知道“文件 X”实际上是“文件 Y”。哦，版本号都被重置了。
我正在从事的项目是一个开源 Java 应用程序，它刚开始规模很小，并且不断发展壮大，因此所有内容都位于“core.*”包中。当需要重构并将内容放入一个漂亮的包层次结构时......好吧，CVS 重置了所有版本信息，因为据它所知，我们刚刚删除了整个“ core/”文件夹并凭空创建了一堆新文件。
据推测，SVN知道文件被移动/重命名，因此它不会破坏版本沿袭。不知道Git是否这样做。
File renaming/moving! Taken alone, I doubt this is a compelling reason to switch, but it did have serious implications on a project I was on, once.
See, CVS doesn't let you rename/move files. If you rename or move a file, CVS thinks that the old one disappeared and the new one appeared, and that there's no connection between them. Although there's no real loss of revision history, you'd have to know that "File X" was actually "File Y" if you go back before some certain date. Oh, and the version numbers all get reset.
The project I was working on was a open-source Java app which had just started small and grew and grew, so everything was just in the package "core.*". When the time came to re-factor and put stuff into a nice package hierarchy... well, CVS reset all of the version info because, as far as it knew, we had just deleted the whole "core/" folder and created a bunch of new files out of thin air.
Supposedly, SVN is aware of files being moved/renamed, so it doesn't break version lineage. Don't know if Git does this.