跨服务器迁移Subversion存储库

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了跨服务器迁移Subversion存储库相关的知识,希望对你有一定的参考价值。

我们正在移动服务器,其中一个最后的项目是移动到svn存储库。

大约有10个各种svn存储库。它们是使用以下命令创建的:svnadmin create --fs-type fsfs

服务器A(原始)具有svn 1.4,而服务器B(目标)具有svn 1.6。

我的想法是使用rsync来迁移整套存储库(它们都在服务器上的1个文件夹中),但我担心有些东西可能无法迁移,或者我需要rsync的特殊开关才能使用。

大多数在线教程只讨论一次移动1个存储库,例如使用svnadmin hotcopy,但我需要一起移动大约100个左右。这是正确的方法吗?

答案

Subversion的FSFS在复制和移动时非常稳定,即使在不同的操作系统上也是如此。虽然mliebelt通过转储重新加载是正确的,但移动10 GB需要很长时间!

这就是我推荐以下程序的原因:

  1. 通过文件系统将存储库复制到新服务器。 例如$ scp -r /var/repos/ user@newServer:repos/
  2. 做一个$ svnadmin upgrade在1.6的存储库上做更新(这是可选的,但强烈建议如果你想使用1.5 / 1.6功能,如合并跟踪,稀疏结账等)
  3. 在每个存储库上执行$ svnadmin verify以验证所有修订都可以(您可以在已经运行的服务器上执行此操作)。

通过这个程序,你需要大约10到100倍的时间:

例如对于转储存储库,它通常每小时约1 GB(很大程度上取决于HD速度),转储文件比存储库大得多(在SVN 1.4中!)所以你必须将较大的文件移动到新的服务器并且做有一个转储负载,也需要大约1小时/ GB。将此与文件系统副本进行比较,如果您有GBit-LAN​​,则该文件系统副本通常仅受网络连接(100 mbit约10 MB /秒)或HD(约100 MB /秒)的限制。

另一答案

首先,我不是Subversion管理员,但我和他们一起工作很多。所以不要只相信我的话,也要检查其他来源。

我过去5年的经历是:

  • 要移动Subversion存储库,您应该使用Subversion管理工具dumpload。它们只是为了那份工作而写的。
  • dumpload另外检查一切都好。通过使用它们,您可以获得额外的“保险”,确保一切顺利。
  • 我们从未迁移过两个主要版本,但是从一个主要版本迁移到另一个主要版本。您至少应该检查是否支持从1.4.x迁移到1.6.x.新服务器版本通常支持直接的先前版本,并支持迁移。因此,您可能必须为每个存储库执行两次迁移。
  • 只要它们正在移动,您就可以使用旧存储库,因为subversion允许您添加更新的更新版本。
  • 因为所有这些都可以通过命令行完成,所以你可以自动完成其中的大部分操作,并且subversion管理员只需检查一切是否运行良好。

所以,是的,我建议将一个存储库相互移动。

另一答案

有关szn 1.6的svnadmin dumpsvnadmin load的更多信息,请参阅here。它提供了关于dumpload的一些讨论,以及--deltas--incremental等选项。

另外,请注意,如果您执行直接复制和svnadmin升级,则可以节省时间,但存储库状态可能不是最佳状态。从svnadmin帮助:

svnadmin help upgrade

用法:svnadmin升级REPOS_PATH

将位于REPOS_PATH的存储库升级到最新支持的架构版本。

提供此功能是为了方便希望使用新Subversion功能的存储库管理员,而无需进行可能代价高昂的完整存储库转储和加载操作。因此,升级仅执行完成此操作所需的最少量工作,同时仍保持存储库的完整性。它不保证最优化的存储库状态为转储和后续加载。

以上是关于跨服务器迁移Subversion存储库的主要内容,如果未能解决你的问题,请参考以下文章

subversion多版本库及导入导出相关迁移

迁移/移动subversion存储库

即使一切看起来都是最新的,Subversion 合并也需要“旧式”?

移动了存储库。我是否使用SVN交换机,SVN重定位或其他所有内容

将 subversion 存储库编号获取到代码中

避免让 subversion 修改 Linux 文件权限。