我正在调查试图让我的团队从 CVS 迁移到 SVN，在我看来 SVN 比 CVS 有很多优势，但是将遗留系统和团队从已经使用了 10 年以上的东西迁移将被证明是困难的。
我试图猜测当我介绍为什么我们应该迁移到 SVN 时会被问到的问题，并且想知道您是否可以填写适当的答案（或者甚至为什么 SVN 在这方面更糟）。
我还将尝试解释我们目前的工作方式，如果您能说出必须更改的内容，我将不胜感激！
目前我们必须对我们的 CVS、HEAD（生产）和测试（TEST）的主要部分
来自 TEST 的代码每晚构建，如果构建成功，则使用新的 CVS 标记进行标记。一旦我们对它感到满意，我们就会将该标签从 TEST 拉到 HEAD 中，然后进行最终构建并部署给用户。
我们广泛使用 CVS 的 $Header$ 功能，它在与代码合并时经常会导致冲突（尤其是反向合并）。
由于 CVS 处理文件单独回滚损坏的提交（甚至看到文件更改）证明是非常困难的（逐个文件）。
在签入时，CVS 倾向于认为你已经接触了很多你没有接触过的文件
综上所述，改用 SVN 对我们有何影响？
谢谢你的时间，
我们广泛使用 CVS 的 $Header$ 功能，它在与代码合并时经常会导致冲突（尤其是反向合并）。
Subversion 足够聪明，可以在执行合并和差异时忽略扩展关键字。
由于 CVS 处理文件单独回滚损坏的提交（甚至看到文件更改）证明是非常困难的（逐个文件）。
由于 Subversion 修订的存储/提交方式，回滚整个提交（修订）实际上比从单个提交（甚至一组提交）中挑选单个项目来回滚更容易。见http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo
在签入时，CVS 倾向于认为你已经接触了很多你没有接触过的文件
I can't say I've ever seen this with Subversion. Perhaps CVS is picking up the changes because the last modified time has been changed, but the file contents haven't? Subversion uses the file's mtime to determine if a change may have happened, then performs an MD5 comparison between the current copy & a pristine copy of what last came from the repository. If the mtimes don't match, but the MD5s do, it's not flagged as a change.