标签: fsfs

当我提交时,我没有错误.现在我试着看看,我收到了这个错误

无法读取文件'c:\ svn\db\revs\0\14'中的长度行

我尝试过较旧的版本也不起作用.这是否意味着我在颠覆中失去了一切？

我最近向我的svn存储库提交了一个大的变更集(~7,000个文件).这7,000个文件仅占使用FSFS后端并与svnserve 1.7一起提供的存储库总大小的5%.从那以后,在这个大型提交之后的结账修改需要花费20倍的时间.

Subversion在内部做什么导致速度减慢,有没有办法解决这个问题？

更新

1. 在手动检查错误的修订版时,我可以看到结帐开始变慢的点.结帐开始是非常快速地将文件添加到工作副本(您无法足够快地读取tty输出).一旦结帐到达某个目录(错误的修订将2,000个文件添加到此目录(其中已包含17,000个文件)),文件将被添加到工作副本中,速度明显变慢(如每秒5个文件),用于其余的结帐.在错误的版本之前进行的修订会在整个时间内非常快速地将文件添加到工作副本中.此目录中的文件各约为1KB.

2. 我svnserve为版本1.6和1.7 编译了我自己的版本--with-debuging和--with-gprof,以便我们可以深入了解正在发生的事情.一些进一步的讨论表明,svnadmin 1.7中与内存缓存相关的一些增强功能实际上是在此版本中将其删除.即,使用svnserve 1.6服务存储库会使这个问题消失.我猜这是在http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning中讨论的内存缓存,它基于gprof配置文件,用于在错误修订时的结帐时间(和之前的那个).在rBAD中,某些svn fsfs到内存缓存函数的调用比rGOOD大约多2,000,000,000倍.

这一切都始于我注意到我的存储库大小以每日1GB的速度增加.我做了一个简单的测试.创建了大小为35KB的现有文件夹的分支/标记.我记下了修订号,然后去了$REPO/db/revs/<K-rev>/rev-number/并检查了修改的大小.这是1兆字节.这听起来很可疑.关于这里可能出错的任何想法.我的回购大小约为350GB,大约有600,000个版本.

PS我已经开始重建整个存储库,看看是否有任何不同,但可能需要数天才能完成.

我使用 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 时，它​​解决了这个问题。

我们有一个相当大的SVN存储库(50 GB,超过100000个版本).使用它非常慢,我的猜测是这样做的原因是db/revs和db/revprops中的平面目录结构(其中每个修订版本是一个文件).

我们将FSFS格式与SVN 1.5(在Linux服务器上)一起使用,但是repo是使用较旧的SVN版本创建的.现在我读到SVN 1.5支持"分片",我知道这个功能将修订版本分发到多个目录中,因此单个目录不包含这么多文件.这听起来非常有用,但不幸的是,这个功能看起来只适用于使用SVN 1.5新创建的存储库.

如何将现有的大型线性仓库转换为分片仓库？手册提到了工具"fsfs-reshard.py",但是这个脚本说"这个脚本未完成,不准备用于实时数据.相信我们.".所以我绝对不想用它.还有其他选择吗？

我遇到了一个 svn 存储库的问题，该存储库到目前为止一直运行良好。

我收到错误

svnadmin: Can't set position pointer in file 'repository/db/revs/0/783': Invalid argument

例如当我跑步时

svnadmin verify

其他一般症状包括无法签出、更新、提交等。

非常感谢任何帮助

谢谢！彼得

我已经在互联网上寻找一个明确的答案,找不到一个.它代表什么？我目前正在尝试为我们的开发团队建立一个新的回购,我想知道这个术语的含义.

我已经创建了我的存储库并且已经使用了一段时间.我想检查它使用的文件系统数据存储:Berkeley DB或FSFS.我不知道怎么检查这个.我看过svnadmin,svnlook等等.有关如何做到这一点的任何提示？

我已经在我的web主机服务器上创建了一个svn repo并成功地将文件提交给它并从中更新了文件,但我似乎无法在服务器上找到这些文件!

我的svn回购~/svn/my-first-repo/包含以下内容:./ ../ README.txt conf/ db/ format hooks/ locks/.

但是我在哪里编辑文件？!

它绝对有效,因为我能够将相同的远程仓库签出到另一个本地目录中并且所有文件都神奇地出现了!好像无处不在......

我想了解subversion如何在FSFS中存储修订版,以及如何为给定的修订版号构建视图/ shapshot.

我从Googling收集到的是FSFS是一个简单的目录结构,每个版本的子目录如下:

..svn/rev/0/
..svn/rev/1/
..svn/rev/2/

据推测,只有每个修订目录下记录的更改(增量).那么这是否意味着在构建修订版N的视图/快照时,必须循环从0到N的所有增量？

任何关于资源的链接都非常赞赏.

谢谢

我遇到了 Apache Subversion 存储库的问题，我正在寻找最佳解决方案：

我无法提交到 Subversion 存储库，并且出现错误：

svn: E720002: Commit failed (详情如下): svn: E720002: Can't open file 'C:\Repositories\myproject\db\txn-current': 系统找不到指定的文件。

如果我创建一个空txn-current文件，如果在提交时会出现另一个错误：

svn: E070014: 提交失败 (详细信息如下): svn: E070014: 无法读取文件 'C:\Repositories\myproject\db\txn-current': End of file found

注意：假设我没有存储库的备份，因此我必须手动修复该问题。

StackOverflow 上已经讨论了相同的行为：svn commit problem, Cannot read 'd:\UC\db\txn-current': End of file found。但是我怀疑那里的答案是否真的有帮助：

• 我不认为\db\txn-current手动创建并放置一个0（或任何其他整数）是一个很好的解决方案。我想它可能会在不久的将来导致一些意想不到的行为，

• svnadmin recover和/或svnadmin verify不创建和/或填充txn-current. 这些命令在这种情况下是无能为力的。

根据FSFS 描述 \db\txn-current文件包含下一个交易密钥号。如果我将一些整数放入文件，那么我可以提交并且整数将增加 1。

然而，看起来像放置一些不相关的整数会破坏我的回购中的某些东西，我不希望这种情况发生。

“txn-current”文件是一个仅包含一个 base-36 数字的单行文本文件。当前值将用于下一个事务名称，以及事务所基于的修订号。该序列号确保事务名称不会被重用，即使事务被中止并开始基于相同修订的新事务也是如此。FSFS 对这个文件执行的唯一操作是“get and increment”；“txn-current-lock”文件在此操作期间被锁定。

我应该怎么做才能\db\txn-current …

是否有关于svn后端数据库的使用,速度和可靠性的基准测试？

• SQLite的
• MySQL的
• PostgreSQL的
• 的BerkeleyDB
• Flatfile系统

假设我们有20个人同时在存储库上工作.选择什么？