从我理解的很少，svn 1.5为合并操作提供了更好的支持。所以我正在考虑从svn 1.4升级。存储库位于本地文件中（或多或少），我从命令行使用svn。
我可以期待什么障碍以及svn 1.5如何在没有合并数据的情况下处理现有存储库？
修改
特别是，在我运行svnadmin upgrade之后，svn将如何处理上次在1.4时代合并的分支的合并？
svn-populate-node-origins-index与此有什么关系吗？
答案 0 :(得分：5)
升级应该是顺利的，但是在填充merge-info之前你不会得到任何神奇的合并好处 - 直到你开始使用它才会发生。
我发现合并信息的唯一实际好处是能够看到两个分支之间潜在合并的列表，并且知道哪些修订已经合并。它不会直接影响生成的冲突数量之类的事情，但可以让您在跟踪已经消失的地方时保持理智。在升级之前执行的合并不会导致问题，即使它们已经完成，它们也会再次显示为潜在的合并。
也就是说，合并信息只是一个名为svn：mergeinfo的svnproperty，格式为：
/Project/name/trunk:1355-3985,4019,4026-4437,4478,4481
这是我们其中一个项目发布分支的实际合并信息，并准确告诉我们即将发布的主干版本。 这意味着，在您需要它的地方，以及您可以解决的地方，您可以手动填充mergeinfo并获得所有好处 - 这就是我们在上面的早期修订中所做的。
查看reshard.py也许是值得的，特别是如果存储库很大并且在Windows上。 1.4 fsfs存储库格式将所有修订版本放在同一文件夹中的单独文件中，Windows在几千次修订后开始使用它进行爬网。 1.5将组修订为每个1000个单独的文件夹。 1.6将允许我们将旧版本组合成一个大型修订文件。
答案 1 :(得分：1)
升级非常简单。在大多数情况下，Subversion是向后兼容的。但是，您应该使用svnadmin upgrade升级存储库。
据我了解，合并跟踪仅适用于升级后的合并。没有真正的方法来重建丢失的信息。
此外，svn-populate-node-origins-index应该在该存储库上运行，但由于链接文件中列出的原因（请参阅usage_summary）。
答案 2 :(得分：0)
根据您的开发环境，您可能需要更新绑定。例如，Netbeans 6.2不适用于SVN 1.5。
答案 3 :(得分：0)
有许多工具可以将存储库从subversion / cvs转换为完全不同的类型。尽量不要争论，我建议你看看所有其他选项，并自己决定是否有任何可以让生活变得更容易，比如分布式版本控制系统。 Git是一个自称更好的人。