跨服务器迁移 Subversion 存储库
我们正在迁移服务器，最后一项是迁移 svn 存储库。
大约有 10 个不同的 svn 存储库。它们是使用以下命令创建的： svnadmin create --fs-type fsfs
服务器 A（原始）具有 svn 1.4，而服务器 B（目标）具有 svn 1.6。
我的想法是使用 rsync 来迁移整套存储库（它们都在服务器上的 1 个文件夹中），但我担心有些东西可能不会被迁移，或者我需要特殊的开关rsync 才能正常工作。
大多数在线教程仅讨论一次移动 1 个存储库，例如使用 svnadmin hotcopy ，但我需要总共移动大约 100 个存储库。这是正确的做法吗？
We're in the process of moving servers and one of the last items is moving over the svn repositories.
There are about 10 gigs of various svn repositories. They were created using this command:svnadmin create --fs-type fsfs
Server A(original) has svn 1.4 while Server B(target) has svn 1.6.
My thought was to use rsync to migrate the whole set of repositories (they are all in 1 folder on the server), but I am worried that some things might either not get migrated or I need special switches for rsync for this to work.
Most online tutorials only talk about moving 1 repository at a time, for example using svnadmin hotcopy, but I need to move about 100 or so all together. Is this the right way to go about it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Subversion 的 FSFS 在复制和移动方面非常稳定，即使跨不同的操作系统也是如此。虽然 mliebelt 通过转储重新加载来实现这一点是正确的，但移动 10 GB 需要很长时间！
这就是为什么我建议执行以下过程：
通过文件系统将存储库复制到新服务器。
例如
$ scp -r /var/repos/ user@newServer:repos/执行
$ svnadmin Upgrade对 1.6 的存储库进行更新（这是可选的） ，但如果您想使用 1.5/1.6 功能（例如合并跟踪、稀疏签出等），强烈建议您这样做。）在每个存储库上执行
$ svnadmin verify以验证所有修订版本好的（您可以在已运行的服务器上执行此操作）。通过此过程，您可能需要减少 10 到 100 倍的时间：
例如，转储存储库通常需要大约每小时 1 GB（很大程度上取决于 HD 速度），转储文件比存储库（在 SVN 1.4 中！）
因此，您必须将较大的文件移动到新服务器并进行转储加载，这也需要大约 1 小时/GB。将此与文件系统副本进行比较，文件系统副本通常仅受网络连接（100 MB 约 10 MB/秒）或 HD（约 100 MB/秒）的限制（如果您有 GBit-LAN）。
Subversion's FSFS is pretty stable on doing copies and movements, even across different OSes. While mliebelt is correct about doing it via dump reload, it takes ages to move 10 GB!
That's why I would recommend the following procedure:
Copy the repositories via filesystem to new server.
e.g.
$ scp -r /var/repos/ user@newServer:repos/Do an
$ svnadmin upgradeto do an update on repository for 1.6 (this is optional, but highly recommended if you want to use 1.5/1.6 features like merge tracking, sparse checkouts, etc.)Do an
$ svnadmin verifyon each repository to verify all revisions are okay (You can do this on already running server).By this procedure you need probably 10 to 100 times less time:
e.g. for dumping a repository it takes usually approx 1 GB per hour (largely depending on HD-speed), the dump files are much bigger than the repositories(in SVN 1.4!)
So you have to move the larger file to the new server and do there an dump-load which also takes approx 1 hrs / GB. Compare this to a filesystem copy which usually is only limited by network connection (100 mbit approx. 10 MB / sec) or HD (approx 100 MB/sec), if you have GBit-LAN.
首先，我不是 Subversion 管理员，但我经常与他们一起工作。所以不要只相信我的话，也要检查其他来源。
我过去 5 年的经验是：
dump和load。它们是专门为这项工作而编写的。dump和load另外检查一切是否正常。通过使用它们，您可以获得额外的“保险”，确保一切顺利。所以，是的，我建议一个接一个地移动存储库。
First of all, I am not a Subversion administrator, but I work a lot with them. So don't trust my words only, check other sources as well.
My experience over the last 5 years was:
dumpandload. They are written just for that job.dumpandloadcheck additionally that everything is ok. By using them, you get additional "insurance" that everything moved ok.So, yes, I would recommend to move one repository after each other.
有关 svn 1.6 的
svnadmin dump和svnadmin load的更多信息，请参阅 此处。它提供了一些有关dump和load的讨论，以及诸如--deltas、--incremental等选项，和其他人。另外，请注意，如果您进行直接复制和 svnadmin 升级，您可以节省时间，但存储库状态可能不是最佳的。来自 svnadmin 帮助：
svnadmin 帮助升级For more info on
svnadmin dumpandsvnadmin loadfor svn 1.6 see here. It offers some discussion ondumpandload, as well as options like--deltas,--incremental, and others.Also, be warned that if you do a straight copy and svnadmin upgrade you save time, but the repository state may not be optimal. From the svnadmin help :
svnadmin help upgrade