ストレージ

Diversion はプロジェクトとその履歴をクラウドに保存します。これにより、どのデバイスからでもプロジェクトにアクセスでき、チームと共同作業ができます。ただし、これは同時に、どれだけのストレージを使用しているか、どのように計算されるかを把握しておく必要があることを意味します。

ストレージはいつ計算される？

ストレージは毎日計算されます。変更を加えてもストレージ使用量に反映されない場合は、翌日まで待ってから再度確認してください。

各ファイルについて

Diversion は、リポジトリ内のファイルの履歴を、そのファイルを変更するコミットごとに1バージョン保持します。つまり、1 MB のサイズのファイルがあり、そのファイルを変更する10個のコミットを行った場合、10 MB のストレージ使用量としてカウントされます。 1 つのリポジトリ内では、内容が同じファイルは 1 回だけ保存され、1 回だけカウントされます。異なるパスにあるバイト単位で同一のファイルや、以前のバージョンと同じ内容のバージョンは、ストレージを増やしません。これはリポジトリをまたいでは適用されません。同じファイルが 2 つのリポジトリにある場合は、それぞれのリポジトリでカウントされます。そのファイルを削除しても、10 MB のストレージ使用量としてカウントされ続けます。なぜなら、そのファイルの履歴はリポジトリに保存されており、以前のコミット（そのファイルを含む）に戻したり、履歴からダウンロードしたりできるからです。同じ理由で、コミットの取り消しやロールバック、大きなファイルの小さなファイルへの置き換え、.dvignore への追加は、ストレージ使用量を減らしません。これらの操作はファイルの現在の状態を変更するだけで、古いバージョンは履歴に残り、カウントされ続けます。管理者は、次の2つの方法でストレージを回収できます：リビジョン制限を設定してマッチするファイルの最新 N バージョンのみを保持し古いものを自動的に削除する方法、または obliterate を使用して特定のファイルとその履歴全体を永久に削除する方法です。リビジョン制限は Studio および Enterprise プランで利用できます。リポジトリを削除したり、マージされていないブランチを削除することでもストレージが減少します。新しいファイルやまだコミットされていない変更を含むファイルもクラウドに同期されるため、ストレージクォータにカウントされます。これらは削除しやすく、ワークスペースから reset するだけでクラウドからも削除され、ストレージにカウントされなくなります。シェルフもストレージクォータにカウントされます。これには、ブランチを切り替えて Save changes for later use を選んだときに作成される自動シェルフも含まれます。シェルフは削除されるまでカウントされ続けます。容量を空けるには、シェルフを削除してください。ストレージは1日に1回再計算されます。

各リポジトリについて

リポジトリごとに、ダッシュボードの Remote Repositories タブの行で、どれだけのストレージを使用しているか確認できます。これは、各ファイルのすべてのバージョンを含む、リポジトリ内のすべてのファイルの合計サイズです。リポジトリを削除すると、そのサイズはすぐに組織のストレージ使用量から差し引かれます。

各組織について

組織については、その組織に割り当てられたすべてのリポジトリがカウントされます。ストレージクォータは組織のオーナーに対して計算されます。組織の合計ストレージは、組織設定の Repositories ページで確認できます。

組織のオーナーまたは管理者が新しいメンバーを招待し、そのメンバーがどの組織にも割り当てられていないリポジトリを持っている場合、それらのリポジトリは自動的に招待側ユーザーの組織に追加され、そのストレージが組織のストレージクォータにカウントされます。また、組織のオーナーまたは管理者が組織に属するリポジトリに新しいコラボレーターを招待した場合、その新しいコラボレーターはメンバーとして追加されます。これらのどちらも避けたい場合は、組織で使用する別の Diversion アカウントを作成することができます。