350GB SVNリポジトリは、Branch/Tagのような最も単純なタスクでさえも少なくとも1MBの改訂を作成します
https://stackoverflow.com/questions/3910387
-
29-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian質問
これはすべて、リポジトリのサイズが1GBの毎日のレートで増加していることに気付いたときに始まりました。簡単なテストを行いました。サイズが35kbの既存のフォルダーのブランチ/タグを作成しました。改訂番号に注意して行きました $REPO/db/revs/<K-rev>/rev-number/ 改訂のサイズを確認しました。 1メガのバイトでした。それは怪しげに聞こえます。ここで何が間違っているのかについてのアイデア。私のレポは約350GBのサイズで、約600,000の改訂版です。
PS私はすでにリポジトリ全体の再構築を開始しており、それが違いをもたらすかどうかを確認していますが、おそらく完了するまでに数日かかるでしょう。
解決
同じ質問をusers@subversion.sapache.orgに投稿し、B Smith -Mannschottからこの答えを得ました。これはすべてを説明しています。 16000フォルダーを含むパスにディレクトリがあります - すべてのコミットについて。詳細な応答をしてくれたB Smith-Mannschottに感謝します。他の人の利益のためにここに返信を投稿してください。
リポジトリには非常に多くのエントリがあるディレクトリが含まれていますか？そのようなディレクトリ内またはその下に行われている大規模なコミットを生み出す変更はありますか？
リポジトリに単一のファイルに単一の変更をコミットすると仮定しましょう。さらに、ファイルがリポジトリにあると仮定しましょう。
/project/trunk/someallylally-large-directory/notes/blah.txt
blah.txtに変更を犯すと、新しいリビジョンは「blah.txt」とリポジトリのルートとの間のディレクトリノードを書き換えます：/project/trunk/some allyly-large-directory/notes、/project/trunk /ある程度の大規模なディレクトリ、 /プロジェクト /トランク、 /プロジェクト、 /。ディレクトリノードを書き換えるとき、FSFは常に新しいバージョンを完全に保存します。 （これは、ファイルへの変更が保存される方法とは異なります。これは、通常、同じファイルの以前のバージョンの違いとして違いです。）
/project/trunk/come wallly-large-directory/contasが10000ファイルを含む場合、それぞれがBlah.txtにコミットすると、リポジトリにこのディレクトリの完全なコピー（10'000名を含む）を保存します。
数年前にバージョンコントロールの下で個人的なWikiを保持し始めたとき、私はこれに気づきました。これは、10'000を超えるテキストファイルのフラットディレクトリでした。コミットがかなり大きいことにすぐに気付きました。 （このタスクやその他の理由で、そのタスクのためにGitに切り替えました。）
他のヒント
非常に簡単な解決策があります。リポジトリに膨大な量の履歴タグが含まれていると仮定すると、それらをに移動できます /tags-archive そして、このディレクトリを読み取らせてください。下に新しいタグを作成するとき /tags 問題はもう発生しません。
URLを使用してURL移動が必要であることに注意してください。例えば
svn move https://svn.example.com/MyRepo/tags https://svn.example.com/MyRepo/tags-archive -m "Your Log Message"
このソリューションは、単一のディレクトリに約350,000のタグを含むリポジトリの問題を解決するのに役立ちました。
