バージョン管理機能において誤解されやすいと感じることが2つあります。
私自身がどちらも誤解したまま覚えてしまっていたため、備忘録という意味も込めて書き残します。
誤解されやすいこと① マイナーバージョンの上限数
下図の設定画面を見て、以下の通りの設定だと理解するかたは少なくないと思います。
- メジャーバージョンの上限数が 10 版
- マイナーバージョン（= 下書き）の上限数が 3 版
実は、下図の設定でマイナーバージョン（= 下書き）の上限が 3 版という理解は誤りです。
この設定画面を英語で表示すると下図の通り。こっちのほうが正しく理解しやいかと思います。
Keep drafts for the following number of major versions
つまり、この設定項目で指定するのは「マイナーバージョンを保持するメジャーバージョンの版数」です。
マイナーバージョンの上限版数の正しい理解
つまり、下図の設定の正しい理解は以下の通りです。
- メジャーバージョンの上限が 10 版
- マイナーバージョン（= 下書き）を保持するメジャーバージョンの上限が 3 版。4 版前のメジャーバージョンが保持していた下書きは自動で破棄する
実際のマイナーバージョンの上限数はいくつ？
マイナーバージョンの実際の上限数は 511 です。
この数値は変更不可のようです。
| 制限 | メモ | メモ | メモ |
|---|---|---|---|
| メジャー バージョン | 400,000 | サポートされている | この制限を超えると、ファイルを開く操作、ファイルの保存と削除、バージョン履歴表示など、基本的なファイル操作を正常に実行できなくなることがあります。 |
| マイナー バージョン | 511 | 境界 | マイナー ファイル バージョンの最大値は 511 です。この制限を超えることはできません。 |
お客様先でSharePoint運用を支援していたときに「特定のファイルを編集しようとすると必ずエラーが発生する」という問い合わせがありました。
調べたところ、マイナーバージョンの数が上限に達して、かつ、ファイルの編集時に必ずチェックアウトをする設定していました。そのため、ファイルの編集を開始しようとしたときにマイナーバージョンの作成できずエラーになったという状況です。
そのときは、メジャーバージョンの発行を実施して頂くことで解決しました。
マイナーバージョンの上限数を誤解していると困ること
マイナーバージョンの上限数を誤解して起こり得るトラブルは、ライブラリの容量が管理者の意図しない範囲で大きく膨らむ場合があることです。
SharePointのバージョン保持は変更部分の差分を保持するのではなく、ファイルそのもののコピーを残すイメージです。そのため、バージョンが増えると単純計算で ファイル × 版数 の空き容量が必要になります。
管理者がバージョン履歴による容量の増大を抑えるためにメジャーバージョンとマイナーバージョンの版数を明確に決めていたとしても、実際にはシステムの上限値である 511 版までマイナーバージョンは保持されます。そのため、気が付いたら管理者が想定していた何倍もの容量がサイトに登録されている（しかもその大部分を占めているのがバージョン履歴の容量）ということが起こり得ます。
バージョン履歴による容量増大を抑えるためには、マイナーバージョンを使わずにメジャーバージョンだけで運用するという割り切りかたも手段のひとつとしてありだと思います。
誤解されやすいこと② 上限数の設定を変えた時に、上限を超えた古いバージョンが削除される？
「サイトで保持するファイル容量を削減するためにライブラリに設定しているバージョンの上限数を減らしたのに、ファイルが保持しているバージョン数が減らない」
という問い合わせをもらったことがあります。
上限数を超えたバージョンが削除されるのは、そのアイテムの更新処理が行われたときのようです。そのため、上限数を減らしたあとに何らかの方法で更新処理を行うまでは古いバージョンは保持されます。
この更新処理のトリガーは、ファイル自体の編集だけでなくアイテムのプロパティ編集でもOKです。なので、手動でアイテムの編集画面を開いて閉じる、という操作でそのファイルの古いバージョンを削除するトリガーになります。
ファイルが大量にあって手動ではきりがない場合は、PowerShell を使って一括で処理することも可能です。
その場合は、Updateメソッドを使うよりも、更新日や更新者を変えない SystemUpdateメソッド を使うほうが望ましいと思います。
削除されたバージョン履歴はごみ箱にはいります。
余談
Microsoft Docs にここ数年で新しく投稿された記事は表現が妙にポップなときがありますね。
パイにたとえた解説
ファームの容量をパイとして考えてみましょう。パイのサイズは、サーバー、ハードウェア リソース (CPU、RAM など)、ストレージ容量、ディスク IOPS、ネットワーク帯域幅、待機時間など、要素の総計を表します。したがって、パイのサイズは、ファームのリソース全体に関連します。つまり、リソース (ファーム サーバーなど) を追加すると、パイのサイズが増加します。