从我理解的一点点来看,svn 1.5为合并操作提供了更好的支持.所以我正在考虑从svn 1.4升级.存储库位于本地文件中(或多或少),我从命令行使用svn.
我可以期待什么障碍以及svn 1.5如何在没有合并数据的情况下处理现有存储库?
编辑:
特别是,在我运行之后svnadmin upgrade
,svn如何处理上次在1.4时代合并的分支的合并?
这svn-populate-node-origins-index
与此有什么关系?
参考:http://subversion.tigris.org/svn_1.5_releasenotes.html
升级应光滑,但是直到上合并信息的东西填充你不会得到任何神奇合并的好处 - 这不会发生,直到你开始使用它.
我已经找到了合并信息的唯一切实的好处是能够看到两个分支之间的潜在合并的列表,并知道哪些修改已经合并.它不会直接影响生成的冲突数量之类的事情,但可以让您在跟踪已经消失的地方时保持理智.在升级之前执行的合并不会导致问题,即使它们已经完成,它们也会再次显示为潜在的合并.
也就是说,合并信息只是一个名为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将允许我们将旧版本组合成一个大型修订文件.