【问题标题】:What are the limitations of svn hotcopy?svn hotcopy有什么限制?
【发布时间】:2011-12-26 10:05:19
【问题描述】:

我们即将升级我们的基础架构并更改正在使用的操作系统(升级到 RHEL5)。

我们还将我们的 SVN 存储库从我们当前的服务器移动到新的 RHEL5 服务器,但是 - 我不确定我们应该如何进行此更改。 我记得曾经读过,如果我使用 hotcopy 命令,创建的副本只能在与进行备份的操作系统具有相同操作系统的机器上恢复。 它是否正确?即使我在 RHEL4 服务器上进行了备份,我是否能够在 RHEL5 服务器上恢复存储库的副本?

另外,如果我们还要升级我们的 SVN 服务器版本,我能否在进行备份的不同版本的 SVN 服务器上恢复副本?

谢谢!

【问题讨论】:

    标签: svn restore


    【解决方案1】:

    if你想改变Subversion主机的基础设施时,hotcopy将是错误的选择。您必须使用 svnadmin dump|load 程序。

    大多数情况下,旧 SVN-repos 的备份可以很容易地在新版本上恢复,但最好阅读使用和计划之间的所有版本之间的更改日志。不记得 1.5 之前的任何内容,但是,AFAIR,FSFS 的 1.5-1.7 升级是透明的。

    无论如何,你可以安装旧版本,将数据加载到 repo 并在它之后更新服务器

    添加:svn load 可以处理以前版本创建的转储,没有任何问题

    【讨论】:

    • 转储/重新加载对于大型存储库来说非常很慢。如果您使用 FSFS,将所有内容文件复制到新服务器是安全的。 FSFS 存储库是平台和向上兼容的
    • @Peter-parker 我知道,但是转储毕竟是可以手动编辑的
    • 为什么要手动编辑转储?!这是阻止转储文件的最佳方法!
    • 不想并且不这样做,但是对于 一些请求,这是获得结果的单一方法(想象“rebase”在SVN,更改作者姓名)和有可能编辑转储而不发生灾难
    • 我不知道你所说的rebase是什么意思,但是要更改作者姓名,只需使用svnadmin setrevprop
    【解决方案2】:

    在 99% 的情况下,您可以使用热拷贝而不是转储来侥幸成功。然而,你和我都知道,只有 1% 的热副本不起作用,你的职业生涯将取决于它。

    因此,请在备份过程中执行svnadmin dump。如果对整个存储库进行svnadmin dump 处理需要太长时间,您可以对最近的更改进行svnadmin dump 处理。

    我同时进行热复制和转储作为备份。

    【讨论】:

      【解决方案3】:

      你不需要 svnadmin hotcopy。

      您对备份的记忆不正确: FSFS 存储库是平台中立的。您可以在 unix 机器或 windows 机器上使用相同的存储库。您还可以升级服务器二进制文件,而无需担心存储库版本。

      只要您有 FSFS 存储库类型,您就可以对所有存储库进行文件复制。 Hotcopy 在大型存储库上非常缓慢。

      为了保持一致性,您应该禁用对源代码库的写访问。 最简单的方法是用这一行创建一个预提交钩子:

      exit 1;
      

      只是为了确保: BDB-Repositories 不是这样,因为 svn 1.3 FSFS 存储库类型是默认的,我假设你有一个 FSFS 存储库。

      但是,检查复制的存储库的完整性至关重要:

      svnadmin verify <PATH_TO_REPO>
      

      在此之后,您对完整性的所有怀疑都应该消失了 ;-)

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2010-10-01
        • 1970-01-01
        • 2010-12-09
        • 2020-04-10
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多