2011-01-17 18 views
11

多くの紹介、スタートガイド、およびSVNに関するドキュメントを読んだ後、私はまだバージョン管理データがどこに格納されているか把握できません。私は物理的に意味する。私はを編集しました。 [1/2 GB]のコードをチェックインしました。レポはわずか数MBです。これはまだ私にとってブードーです。そして、コーダーとして、私はマジックを本当に信じていません。Subversionは物理的にどこのデータベースを保存しますか?

編集: 寄稿者は、すべてのコードがレポに保存されているわけではないと述べました。私は自分のローカル作業コピーを削除してもリポジトリのソースコードを返すことができます... もしそうなら、私はまだそのような圧縮が私のコードでどのように起こるのか理解できません...

EDIT 2: リポジトリにコードをインポートすると、「50MBアップロード」というメッセージが表示され、実際のリポジトリははるかに小さくなります。圧縮アルゴスが関与している必要があります。

ところで、それは

+8

実際に10 GBのコードがありますか?それは、MS Windowsに入っているすべてのソースコードよりも大きい、大量のコードです。私は単にそのサイズを信じていません。 – abelenky

+0

物理的な場所は、データベースが置かれているコンピュータがどこにあっても... – JasCav

+3

この回答が間違っている人が何人いるのか驚いています。 .svnフォルダは、サーバがファイルを保存する場所ではありません。(マシンにローカルなので、誰もその情報をチェックアウトできません)、SVNはdiffs(FSFSと仮定します)を保存するだけですが、まあまあ。 – JasCav

答えて

6

ミカのリクエストごとに、その答えとしてこれを置く:私は多くの人々は、この答えは間違って持っているかによって驚い

。 。svnフォルダは、サーバがファイルを保存する場所ではなく(マシンのローカルなので誰もその情報をチェックアウトできません)、SVNはdiffs(FSFSと仮定します)を保存するだけですが、どこか。

もちろん、@ csharptest.netは「私の推測では70%がperfデータで、29.99%がobjとbinディレクトリにあります。実際のコードを10mbチェックインしておきます。 "とにかくすべての情報を実際にチェックインしているわけではありません。そのほとんどは決してリポジトリに入りません。さらに、SVNは多くの圧縮アルゴリズムとさまざまな手法を使用し、必ずしもバイト単位でデータをリポジトリに格納するとは限りません。それはあなたがサイズの違いを見ている理由かもしれません。

SVNの詳細については、Stackoverflow answerでお読みください。

希望に役立ちます!

+0

ありがとう、それは洞察だった –

1

それは中に保存されている...いくつかの回答を読んで、実際に魔法を信じますどのように多くの人々を参照し、本当に舞台裏で何を知らなくても、SVNを使用するように面白いですファイルシステム。正確には、システムがどのように設定されたかによって異なります。また、新しいリポジトリを作成するときは、ファイルシステムのどこにでも置くことができます。インストールにはデフォルトの場所がありますが、どこにでも新しいリポジトリを作成することができます。実際のパスを探すには、周りを見回す必要がありますか?これは、そうのようなコマンド・ライン・バージョンで行われる

:のマウントを見たとき、また

:上記の例で

svnadmin create d:/path_to_repository 

、リポジトリは「/ path_to_repository D」に格納されます。あなたのローカルマシンにあるコードは、サーバーに入っていないコンテンツを除外していますか?ソース管理でビジネスを持たない項目を除外するグローバルな無視リストが必要です。 (ユーザが変更したコンテンツ、通常はコンパイルされたプロジェクトなど)あなたはリポジトリの実際のサイズを過大評価するかもしれません。

+0

はいソースコードフォルダのコンテンツの70%をフィルタリングしていますが、まだ3GBから数MBに及ぶのは非常に驚きです –

-2

バージョン管理された各フォルダー内の.svnフォルダー。

+2

@Eric Gagnon:.svnはクライアントの状態を追跡するためのものであり、svnリポジトリ自体ではありません。 – tawman

+2

@Eric - これはリポジトリではないためです。メタデータですが、実際のリポジトリファイルではありません。 (私はどちらの場合でもダウンダウン者ではないが、答えは間違っている) – JasCav

+0

Ok ...ミカが求めていたのは「Subversionデータベース」と「バージョン管理データ」だと思った。私はちょうどそのときの質問を誤解した。 –

7

Subversionサーバーで使用している機能によって異なります。 VisualSVN Serverを使用し、リポジトリファイルをc:\ Repositoriesに保存します。

+0

私のカスタムE:\ SVNレポはほんの数MBです –

3

あなたのsvnリポジトリは、ファイルシステム内のフォルダに保存されています。conf, dav, db, hooks, locksのようなサブフォルダが必要です。これらのフォルダはリポジトリを構成します。

リポジトリの管理に使用できるsvnadminツールがあります。

1

新しい作業コピーをチェックアウトしてビルドし、それでも機能することを確認してみませんか?私たちはここで答えを書いて、どこにいるかもしれないかを推測することができますが、最終的にはSubversionに追加する必要があるすべてのものをチェックする必要があります。

+0

あなたは正しいです。そして、私が通常この種を主張する前に、物事、そしてはい、私は別の開発者のワークステーションでチェックアウトしていて、すべてうまくいきます。 –

0

これは古いスレッドであることを認識していますが、それを読んだ後、私は$ 0.02を投げ込むと思っていました。作業コピーに設定された大規模なローカルファイルへの寄与因子

は、次のとおりです。

  • 述べたように、作業コピーのメタ/状態データは、隠された(デフォルトでは).svnディレクトリに住んでいます。メタデータはかなり小さいですが、作業コピーの各ファイルについては、作業コピーのベースラインがあります。これにより、リポジトリ内に存在するすべてのファイルで消費されるディスク容量が2倍になります。

  • リポジトリにコピーされたパス(ブランチやタグの場合に典型的)が含まれていると、実際に使用されている物理スペースの何倍ものスペースで終わる可能性があります。これは、SVNリポジトリで「論理」コピーを使用する実空間が小さいためです。実際にはソースパスの特定のリビジョンに戻るポインタです。リポジトリ全体をコピー操作で複製して、数百バイトの新しいリポジトリデータを作成することもできます(これは、すべてのコピー操作が同じ短時間で行われる理由です)。それでも、作業コピーをチェックアウトまたは更新すると、コピーする前の2倍の大きさになる可能性があります。これは通常、ルートからリポジトリ全体を再帰的にチェックアウトするのではなく、スイッチ操作を使用して作業コピーを論理的にコピーされたパスのブランチまたはタグに変更する理由です。

私もどのようにコンパクトにSVNを格納し、そのリポジトリデータを転送することにより、非常に感銘を受けてきました。

関連する問題