我试图解决的问题与Subversion out of sync with production code, easiest way to update subversion没有什么不同，但有些不同。
我将（Java）项目从CVS转换为SVN（使用cvs2svn，保留完整历史记录） - 比如版本1.00
版本2.00的开发继续使用SVN中的代码。
同时，在CVS中完成了一些修复（因为开发工具设置不同。）
现在，我需要做的是从CVS中有效地重新导入部分项目。
如果我有
cvs:project/module1 (version 1.00)
/module2 (version 1.10)
和
svn:project/trunk/module1 (version 2.xx)
/module2 (Version 1.00)
有没有办法从CVS重新导入module2并保留完整的历史记录？
我在CVS存储库上再次运行cvs2svn，并将其作为另一个项目加载到SVN中，然后进行无基础合并 - 但我不确定这是否是一个好主意。
我将继续在SVN中维护1.xx版本。
答案 0 :(得分：0)
您可以将当前的CVS repo转换为新的虚拟SVN仓库。使用它，您可以挑选修改以转储并将这些转储重放回真正的SVN仓库。 （我不知道这将如何处理在真正的SVN和CVS /虚拟SVN中同一文件被更改的情况。您可能希望通过将樱桃挑选的转储重放到特定的方式来避免发现这种情况。分支。）
但是，可能有更好的方法，这可能根本不起作用。我只有一个CVS回购转换成SVN回购，这是一个痛苦的一次性任务。因此，需要先加入大量的盐，然后先在副本上干燥。
答案 1 :(得分：0)
由于我将在SVN中维护1.xx版本，并且我知道代码在什么时候发散，我应该只能合并迁移到SVN后创建的更改列表。 这看起来会让事情变得最整洁。
我正在试验这一点。
答案 2 :(得分：0)
根据您引用的版本号，看起来module1上的所有转换后提交都在Subversion中，并且module2上的所有转换后提交都在CVS中。如果是这种情况，您可以尝试以下方法：
使用与以前相同的cvs2svn选项再次转换整个CVS项目。如果幸运的话，生成的Subversion存储库的r0：rN（其中N是某个数字）将与第一次转换产生的Subversion存储库的重叠部分一致。在这种情况下，您应该能够从新的Subversion存储库中“svnadmin dump --incremental -rN：HEAD”并在旧的Subversion存储库之上“svnadmin加载”它。组合存储库中的提交不会按时间顺序排列，但这是一个小麻烦（并且可能使用其他一些工具修复，但代价是重新编写Subversion提交）。
（Subversion存储库的重叠部分不一定是相同的; cvs2svn使用一些启发式来推断变更集，并且由于其他变化，它们的推算可能会有所不同。但只要有可识别的“1.00”修订版在每个具有相同内容的存储库中，我认为该过程应该有效。）
在尝试之前进行备份！