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