350GB SVN repo 甚至为分支/标记等最简单的任务创建至少 1MB 的修订版 [英] 350GB SVN repo creates atleast 1MB revision for even a simplest task like branch/tag
问题描述
这一切都是从我注意到我的存储库大小以每天 1GB 的速度增加时开始的.我做了一个简单的测试.创建了一个大小为 35KB 的现有文件夹的分支/标签.我记下修订号并转到 $REPO/db/revs/ 并检查修订版的大小.它是 1 兆字节.这听起来很可疑.关于这里可能有什么问题的任何想法.我的存储库大小约为 350GB，包含大约 600,000 次修订.
This all started when I noticed that my repository size is increasing at a daily rate of 1GB.
I did a simple test. Created a branch/tag of an existing folder that had a size of 35KB. I took note of revision number and went to $REPO/db/revs/<K-rev>/rev-number/ and checked the size of the revision. It was 1 mega byte. That sounds fishy.
Any ideas on what might be wrong here. My repo is about 350GB in size with about 600,000 revisions.
附言我已经开始重建整个存储库，看看这是否有什么不同，但可能需要几天时间才能完成.
P.S. I have already started a rebuild of the whole repository to see if that makes any difference but it will probably take days to complete.
推荐答案
向 users@subversion.sapache.org 发布了相同的问题，并从 B Smith-Mannschott 那里得到了这个答案 - 这解释了一切.我确实在包含 16000 个文件夹的路径中有一个目录 - 对于每次提交.感谢 B Smith-Mannschott 的详细回复.为了他人的利益，在此处发布回复.
Posted same question to users@subversion.sapache.org and got this answer from B Smith-Mannschott - which explains everything. I do have a directory in the path that contains 16000 folders - for every commit. Thank you B Smith-Mannschott for the detailed response. Posting reply here for others' benefit.
您的存储库是否包含一个包含很多条目的目录?是产生大量提交的更改在这样的范围内或以下进行目录?
Does your repository contain a directory with very many entries? Are the changes that produce the large commits being made in or below such a directory?
让我们假设将对单个文件的单个更改提交到您的存储库.让我们进一步假设该文件位于此处，在您的存储库:
Let's assume to commit a single change to a single file to your repository. Let's further assume the file is located here, in your repository:
/project/trunk/some-really-large-directory/notes/blah.txt
/project/trunk/some-really-large-directory/notes/blah.txt
当您将更改提交到 blah.txt 时，新修订将重写'blah.txt' 和存储库根目录之间的目录节点:/project/trunk/some-really-large-directory/notes,/project/trunk/some-really-large-directory,/project/trunk,/project,/.重写目录节点时，FSFS 总是存储新版本整体而言.(这与更改文件的方式不同存储，通常作为与某些以前版本的差异同一个文件.)
When you commit the change to blah.txt, the new revision will rewrite the directory nodes between 'blah.txt' and the root of the repository: /project/trunk/some-really-large-directory/notes, /project/trunk/some-really-large-directory, /project/trunk, /project, /. When rewriting a directory node, FSFS always stores the new version in its entirety. (This is different from the way changes to files are stored, which are generally as differences to some previous version of the same file.)
如果/project/trunk/some-really-large-directory/包含，比如说 10000文件，然后每次提交到 blah.txt 将存储此文件的完整副本存储库中的目录(包含 10'000 个名称).
If /project/trunk/some-really-large-directory/ contains, say 10000 files, then each commit to blah.txt will store a full copy of this directory (with its 10'000 names) in your repository.
当我开始在 version 下保留个人 wiki 时我注意到了这一点几年前控制.这是一个包含 10'000 多个文本的平面目录文件.我很快注意到提交非常大.(我从出于这个原因和其他原因，为了该任务切换到 git.)
I noticed this when I started keeping a personal wiki under version control a few years ago. It was a flat directory of over 10'000 text files. I quickly noticed that commits were pretty big. (I've since switched to git for that task, for this and other reasons.)
这篇关于350GB SVN repo 甚至为分支/标记等最简单的任务创建至少 1MB 的修订版的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
