我正在调查试图让我的团队工作从CVS转移到SVN，在我看来，SVN比CVS有许多优势，但遗留系统和团队已经使用了10年以上的事情将证明是困难的。
当我提出为什么我们应该转移到SVN并且想知道你是否可以填写适当的答案（或甚至为什么SVN在这方面更糟）时，我试图再次猜测会问的问题。
我还会尝试解释我们目前的工作方式，如果你能说出必须改变的话，我会很感激！
目前我们必须使用CVS，HEAD（生产）和测试（TEST）的主要部分
TEST的代码是每晚构建的，如果构建成功，则使用新的CVS标记进行标记。一旦我们对它感到满意，我们将该标签从TEST拉到HEAD，然后进行最终构建并部署到用户。
我们广泛使用CVS $ Header $功能，这在与代码合并时经常会导致冲突（尤其是反向合并）。
由于CVS处理单独回滚破坏的提交（甚至看到文件已更改）的文件证明非常困难（逐个文件）。
在办理登机手续时，CVS倾向于认为你已经触及了许多你没有接近的文件
总之，改用SVN将如何影响我们？
感谢您的时间，
答案 0 :(得分：1)
我们广泛使用CVS $ Header $功能，这在与代码合并时经常会导致冲突（尤其是反向合并）。
Subversion足够智能，可以在执行合并时忽略扩展的关键字。的diff。
由于CVS处理单独回滚破坏的提交（甚至看到文件已更改）的文件证明非常困难（逐个文件）。
由于存储/提交了Subversion修订版，实际上更容易回滚整个提交（修订版），而不是从单个提交中挑选单个项目（甚至是一组提交） ）回滚。见http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo
在办理登机手续时，CVS倾向于认为你已经触及了许多你没有接近的文件
我不能说我曾经见过Subversion。也许CVS正在接受更改，因为上次修改时间已经更改，但文件内容没有？ Subversion使用文件的mtime来确定是否发生了 的更改，然后在当前副本和＆amp;之间执行MD5比较。最后来自存储库的原始副本。如果mtimes不匹配，但MD5不匹配，则不会将其标记为更改。