升级到SVN 1.5
据我所知，svn 1.5 对合并操作提供了更好的支持。 所以我正在考虑从 svn 1.4 升级。 存储库位于本地文件中（或多或少），我从命令行使用 svn。
我会遇到哪些障碍？ svn 1.5 将如何在没有合并数据的情况下处理现有存储库？
编辑： 特别是，在我运行 svnadmin update 后，svn 将如何处理来自 1.4 时代最后合并的分支的合并？
svn-populate-node-origins-index 与此有什么关系吗？
From the little I understand, svn 1.5 provides much better support for merge operations. So I'm considering upgrading from svn 1.4. The repository sits in a local file (more or less), and I use svn from the command line.
What hurdles can I expect and how will svn 1.5 handle the existing repository without the merge data?
edit:
In particular, after I run svnadmin upgrade, how will svn handle merges from branches who were last merged in the 1.4 era?
And does svn-populate-node-origins-index have anything to do with this?
Reference: http://subversion.tigris.org/svn_1.5_releasenotes.html
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
升级应该很顺利，但是在填充合并信息之前，您不会获得任何神奇的合并好处 - 这在您开始使用它之前不会发生。
我发现的合并信息的唯一实际好处是能够查看两个分支之间的潜在合并列表，并知道哪些修订已经被合并。 它不会直接影响生成的冲突数量等事情，但确实可以让您在跟踪发生了什么时保持理智。 升级之前执行的合并不会导致问题，它们只是再次显示为潜在合并，即使它们已经完成。
也就是说，合并信息只是一个名为 svn:mergeinfo 的 svnproperty，格式如下：
这是我们项目发布分支之一上的实际合并信息，并准确地告诉我们主干将要发布哪些修订。
这意味着，在您需要的地方以及可以解决的地方，您可以手动填充合并信息并获得所有好处 - 这就是我们在上面的早期修订中所做的。
也可能值得查看 reshard.py，特别是如果存储库很大并且在窗户上。 1.4 fsfs 存储库格式将所有修订版放在同一文件夹中的单独文件中，Windows 在几千个修订版后开始对此进行爬行。 1.5 分片将修订分组到单独的文件夹中，每个文件夹有 1000 个。 1.6 将允许我们将旧的修订版合并到一个大的修订版文件中。
The upgrade should be smooth, however you won't get any magical merge benefits until the merge-info stuff is populated - which doesn't happen until you start using it.
The only tangible benefit of the merge info I've found is being able to see a list of potential merges between two branches and know which revisions have already been merged. It doesn't directly affect things like the number of conflicts that are generated, but does allow you to keep sane when tracking what's gone where. The merges performed before the upgrade don't cause problems, they just show up again as potential merges even though they've already been done.
That said, the merge info is just an svnproperty called svn:mergeinfo, of the format:
This is the actual merge-info on one of our project release branches and tells us exactly what revisions from trunk are about to be released.
This means that, where you need it, and where you can work it out, you can populate the mergeinfo manually and get all the benefits - that's what we did for the early revisions, above.
It might also be worthwhile looking at reshard.py, especially if the repository is large and on windows. The 1.4 fsfs repository format put all the revisions in separate files in the same folder, windows starts crawling with this after a few thousand revisions. 1.5 sharding groups revisions into separate folders of 1000 each. 1.6 will allow us to combine the old revisions into a single large revision file.
升级非常简单。 Subversion 在大多数方面都是向后兼容的。 但是，您应该使用
svnadmin update升级您的存储库。据我了解，合并跟踪仅适用于升级后的合并。 没有真正的方法可以重建丢失的信息。
另外， svn- populate-node-origins-index 应该在该存储库上运行，但出于链接文件中列出的原因（请参阅 use_summary）。
Upgrading is straightforward. Subversion is backwards-compatible in most regards. However, you should upgrade your repository using
svnadmin upgrade.As far as I understand this, merge tracking will only work for merges after the upgrade. There is no real way to reconstruct the missing information.
Also, svn-populate-node-origins-index should be run on that repository, but for the reason laid out in the linked file (see usage_summary).
根据您的开发环境，您可能需要更新的绑定。 例如，Netbeans 6.2 不适用于 SVN 1.5。
Depending on your development environment you might need updated bindings. Netbeans 6.2 for example doesn't work with SVN 1.5.
有很多工具可以将存储库从 subversion/cvs 转换为完全不同的类型。 尽最大努力不要争论，我建议您查看所有其他选项，并自行决定是否有任何选项可以使生活变得更轻松，例如分布式版本控制系统。 Git 声称自己更好。
There is many tools to convert a repository from subversion/cvs to a completly different kind. Trying hardest not to be argumentative, I suggest you look at all the other options and decide for yourself if any can make life any easier like distributed version control systems for example. Git is one that claims to be better.