13

我们正在移动服务器，最后一项是移动 svn 存储库。

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

服务器 A（原始）具有 svn 1.4，而服务器 B（目标）具有 svn 1.6。

我的想法是用来rsync迁移整个存储库集（它们都在服务器上的 1 个文件夹中），但我担心有些东西可能不会被迁移，或者我需要特殊的开关才能rsync使其工作。

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

4

3 回答 3

15

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

这就是为什么我会推荐以下程序：

  1. 通过文件系统将存储库复制到新服务器。
    例如$ scp -r /var/repos/ user@newServer:repos/

  2. 对$ svnadmin upgrade1.6 的存储库进行更新（这是可选的，但如果您想使用 1.5/1.6 功能，如合并跟踪、稀疏签出等，强烈建议您这样做）

  3. 在每个存储库上执行一次$ svnadmin verify以验证所有修订是否正常（您可以在已经运行的服务器上执行此操作）。

通过这个过程，您可能需要的时间减少 10 到 100 倍：

例如，对于转储存储库，通常每小时大约需要 1 GB（主要取决于 HD 速度），转储文件比存储库大得多（在 SVN 1.4 中！）因此您必须将较大的文件移动到新服务器和是否有转储负载也需要大约 1 小时 / GB。将此与通常仅受网络连接（100 mbit 约 10 MB/秒）或 HD（约 100 MB/秒）限制的文件系统副本相比，如果您有 GBit-LAN​​。

于 2011-10-05T23:57:23.423 回答
3

首先，我不是 Subversion 管理员，但我经常和他们一起工作。所以不要只相信我的话，还要检查其他来源。

我过去5年的经历是：

  • 要移动 Subversion 存储库，您应该使用 Subversion 管理工具dump和load. 它们只是为那份工作而写的。
  • dump并load另外检查一切是否正常。通过使用它们，您可以获得额外的“保险”，一切正常。
  • 我们从未迁移超过 2 个主要版本，而是从一个主要版本迁移到下一个主要版本。您至少应该检查一下，是否支持从 1.4.x 迁移到 1.6.x。通常新的服务器版本支持直接上一个版本，并且支持迁移。因此，也许您必须为每个存储库进行两次迁移。
  • 只要旧存储库在移动，您就可以使用它们，因为 subversion 允许您添加以后的更新版本。
  • 因为一切都可以通过命令行来完成，你可以将其中的大部分自动化，而颠覆管理员只需要检查一切是否运行良好。

所以，是的，我建议一个接一个地移动一个存储库。

于 2011-10-05T19:47:48.180 回答
3

有关svn 1.6的更多信息svnadmin dump，请参见此处。它提供了一些关于和的讨论，以及诸如、等选项。svnadmin loaddumpload--deltas--incremental

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

svnadmin help upgrade

用法：svnadmin 升级 REPOS_PATH

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

提供此功能是为了方便存储库管理员使用新的 Subversion 功能，而不必进行可能成本高昂的完整存储库转储和加载操作。因此，升级只执行完成此任务所需的最少工作量，同时仍保持存储库的完整性。 它不能像转储和后续加载那样保证最优化的存储库状态。

于 2012-11-06T15:47:12.193 回答