问题标签 [fsfs]

我在网上搜索并没有给出一个好的答案，但由于某种原因（升级到 TortoiseSVN 1.9.0 之后？）我的 Subversion 修订日志文件格式已经改变，这让 Jenkins SVN 插件感到困惑，我我很困惑为什么。

在.../Repository/db/revs/0中，查看修订文件的尾部，我得到以下内容tail -n40 116，即较旧的修订：

对于tail -n21 117, HEAD 修订版：

是否有一些工具可以将这些DELTA修订日志转换为PLAIN格式，或者有一些设置可以防止DELTA创建修订？

更新：此错误报告中描述了这似乎导致的问题。

我使用 tarball 在 UAT Linux redhat 6.6 中安装了 SVN 1.9.2，并将 SVNSERVE 作为守护进程运行，一切正常。然后我创建了一个存储库并配置了客户端访问的存储库，并尝试使用 tortoiseSVN 访问存储库但无法访问存储库。看到错误，

“db/format 包含无效的文件系统格式选项寻址逻辑”

在 UAT 中安装之前，我尝试了 TEST 服务器，但我可以毫无问题地安装和访问存储库。我正在使用 Redhat 6.6 服务器。任何人都看过这个问题。我被困住了，因为下周我们有生产安装。

编辑：实际上我移动到 SVN 安装的 bin 目录并启动 svnserve 作为守护进程。启动的 svnserve 是 Redhat OS 附带的。当使用完整路径调用 svnserve 时，它​​解决了这个问题。

我们正在考虑使用 Subversion 作为文件系统层来存储启用版本的文档。由于安全功能将由其他代码处理，我正在考虑直接使用 Subversion FS C API 层。我想知道是否有使用 Subversion FS API 的好的示例代码？

我已经重置了我的 Raspberry Pi（运行的垃圾太多）。我想我可以简单地使用我的备份来让 SVN 再次运行。问题来了：我的备份（每天，全自动）只是将所有文件夹和文件复制到 FTP-Web 服务器。现在我刚刚将它下载到我的 Windows-PC 并通过 WinSCP 将其复制到 Raspberry Pi（首先我使用 sudo svnadmin create 创建了文件夹），我删除了所有现有文件和文件夹，并用 FTP 服务器中的内容替换了它们- 应该一样吗？之后我设置了权限，现在它应该可以工作了。但它没有 - 这是问题所在（当试图用谷歌浏览器打开 svn 时） - 有这条消息：

apache-error 日志也​​记录了问题：

你们中有人知道我可以做些什么来使我的存储库再次工作吗？

非常感谢，多米尼克

更新（1）： 我已经修复了一些会导致问题的文件。现在，当我尝试转储我的存储库时，出现以下错误：

更新(2)

现在我修复了一些文件（似乎是编码问题或类似问题）。我遇到了很多错误，如下所示：

我修复了它们：打开文件删除了 null 所在的空间（看起来像一个普通空间......）并创建了一个新空间（简单地使用 windows 编辑器）。这解决了这个问题，但它只适用于前 9 个文件，现在我收到另一个错误：

我已经尝试过同样的事情 - 删除长度后的空格和最后一个（空行），但这对我不起作用。你有什么想法吗？

以后我会使用dump 来做一个dump 并将dump 保存到我的ftp-server。但即使进行了这些修改，转储也不起作用 - 当尝试转储 r 0-9 或 r 1 时，会出现以下错误：

在此先感谢，多米尼克

我有几个基于 FSFS 的文件系统 SVN 存储库，我希望将它们切换为只读。我可以启用一个标志来阻止 svn 客户端写入存储库吗？

或者，我可以简单地从文件夹中删除所有写权限，但这感觉有点矫枉过正。

我使用 Subversion Edge 5.1.4 和 Subversion 1.9。使用版本 1.9 的首要原因是新的 FileFormat 版本 7（更好的性能）。但是每次我创建一个新的 repo oder 时，都会从旧的 repo oder 加载一个转储（使用 FSFS 4）——它只会生成 FSFS 版本 6。

我如何获得 FSFS 版本 7 的 repo？

谢谢

首先，我已经阅读了有关处理看似相对较小的 SVN 损坏的各种帖子。我发布此消息是因为我们担心腐败的绝对数量意味着我们的方法存在缺陷，或者我们导致成功的恢复选项更加有限。

我们目前正在运行一个大约 8 年历史的 VisualSVN 2.1.3 存储库 (SVN 1.6.12)，在 Windows 文件共享上运行大约 50,000 个修订版，用于 FSFS 支持。根据 VSVN 历史，存储库的早期部分很可能在 VSVN 的早期版本上运行，因为最早的修订版本早于当前运行的版本发布日期。

该存储库有许多子项目。人们倾向于在子树上工作，而不是在整个 repo 上工作。

作为升级我们的一些内部工具和基础设施的一部分，我们遇到了各种行业标准工具，它们报告了回购中缺少的尾随换行问题，除非我们将它们限制在最近的 1500 个左右的修订版中。需要注意的是，在我们运行这些工具之前，没有任何迹象表明开发团队每天都有任何问题。

所以我们开始运行 svnadmin verify，它立即将第 3 次提交高亮显示为无效，第 4 次和第 11 次等等。在尝试手动找到好点之后，我们编写了一个脚本来调用 svnadmin verify -r X 对每个单独的修订。

最后，它报告说我们的 1,000 多个提交是不可验证的（我们意识到 1 个错误的修订也将强制任何受影响文件的下一个修订也是不可验证的，至少会使损坏计数增加一倍）。腐败分散在时间线的大部分时间，从 8 年前到大部分 6 年前（过去 2 年有一次错误提交）

1. 对于大部分似乎在运行的存储库来说，这似乎相当高 - 我们的验证计划是否存在缺陷？
2. 假设不是，这似乎是一个很高的数字，我们能找到的关于该主题的唯一文章暗示大提交可能是一个问题，但我们似乎比大提交更常见的问题。

在这一点上，我们只完成了验证阶段以识别不良修订，但尚不清楚哪些代码受到影响。可能所有的腐败都在死的项目/分支上，或者不是。

我们正在寻找根据损坏数量/存储库大小推荐哪种方法。所有恢复选项都包括升级到更新的 VSVN 版本和改进我们的 SVN 维护实践。

选项 A - 增量转储/加载/比较 - 现在我们已经确定了所有错误的修订，我们可以执行增量转储跳过错误的修订。然后我们可以将这个转储加载到一个新的 repo 中，svn diff 这两个 repos 并查看不匹配的内容并修补剩余的差异。我们会丢失一些历史记录，但是根据损坏的具体情况，我们可以手动修补很多文件，也可以只修补很少，这取决于它们是否相关。但是大量的手工工作。

选项 B - 导出/导入 - 尝试将当前版本的 repo 导出到新的 repo 中，丢失所有历史记录。仍然会比较理智，但不会预期会有很多差异。

选项 C？

谢谢！

我使用svnadmin hotcopy --incremental命令创建备份。颠覆 1.9.5。发现此命令在目录 db/revs/ 中重新创建大小超过例如 120kb 的已备份修订文件。备份日志（第一次备份到空文件夹，下一个备份到同一文件夹）：

依此类推，每个下一个svnadmin hotcopy --incremental命令。原始存储库和备份的二进制比较修订版 14、21、22 文件给出相同的结果。这种奇怪行为的原因是什么？

我正在尝试将 subversion 服务器从 1.6 升级到 1.9，我已经安装了 mod_dav 模块和 svn 二进制文件。svn 1.9 的最大特点是 FSFS 文件系统格式 7，它有很多功能，为了启用所有这些功能，我只是在运行命令 svnadmin upgrade ，它给了我以下输出

这里根据发行说明，启用所有格式 7 功能，FSFS 逻辑寻址：是（以前是否），所以我的问题是如何将上述属性设置为是

我在存储小型和大型 (+1GB) 文件的 Apache HTTPS 服务器后面有一个 SVN 存储库。当我提交一个大文件时，传输速度大约为 10MB/秒（使用 1GBit 网络线路）。当我查看服务器上的 CPU 利用率时，它已经饱和，大约 85% 被 apache2 消耗，大约 15% 被磁盘驱动程序消耗。

我已经尝试禁用 Apache 日志记录和 SSL，但这无助于提高传输速度。这让我觉得mod_dav_svn是占用了大部分的CPU？我还尝试增加服务器上可用核心的数量（默认 = 1 个核心），但这会莫名其妙地减慢提交速度，而 httpd 仍然使用 1 个核心。并且设置SVNCompressionLevel 0也没有导致任何明显的速度提升。

有没有办法通过并行化或其他优化来显着提高传输速度？

服务器：

• Debian 9.3
• 阿帕奇 2.4.25
• libapache2-mod-svn 1.9.5
• svn 存储库：默认 FSFS 配置（即在 中全部注释掉fsfs.conf）。HDD 可以写入高达 30Mb/秒（硬件受限）而不会使 CPU 饱和（通过复制测试）。FS 是 NTFS，使用ntfs-3gwith big_writesenabled 在写入 @10MB/sec 时使用大约 10-15% CPU。

客户：

• svn 1.8.13

CPU：第一代英特尔酷睿@3.20Ghz

显然，如果我能以 25-30MB/秒的速度传输，我会非常高兴。