質問: 昔はファイルサーバー+アップデート担当者、それから次の時代はCVS、今はSubversionを使っています. Subversion以前は、ほぼプログラムの置き場程度の使い方、作り方だったのですが、さすがに今ではそんな管理ではとても開発の現場の動きについてゆけません.このため、 * 基本的には受託の顧客単位のリポジトリがあり * リポジトリには`/trunk`、`/branches`、`/tags` があります. およその使い方のルールは以下のようなものです. * 顧客からの依頼/開発コンポーネント毎にブランチを切って、開発はそこで集中的に行います.開発が終わってメンテナンスフェーズに入れば、`/trunk`にマージします. * しかし、現在運用しているプログラムで不具合報告が上がれば、`/trunk`からブランチを切って、そこで障害対応を行い、修正完了できれば`/trunk`にマージします. * あとプログラム開発の単位をバージョンNNというように切り分けるのがなかなか難しいのですが、さすがに年度単位で発注/納品は完了しますので、その際は`/tags`に`/trunk`から移します.(ブランチを切ります) 聞きたいことはこのようにバージョン管理に馴染むものと、そうでないものの使い分けです.顧客単位のプロジェクトなので、リポジトリ割り当ては1つなんですが、以下のようなものも管理しなければなりません. * ドキュメント類(これは大きな量にならないのでそんなには問題にはならない) * 顧客から渡されるテストデータ(どうしても開発メンバー間で共有して取っておかねばならないのですが、たまに膨大なサイズになります) * フォントなど(最近はNotoフォントなんかを使うお客様がいるので、環境を一気に作れるようSubversionに入れています.大きいですね) * 直接顧客にリリースするプログラムではありませんが、データをコンバージョンしたり、検証を行うために開発/使用するユーティリティ的なプログラム このようなものも`/trunk`に入れるとします.そうすると上記のファイル類を入れたタイミングと`/trunk`から開発/障害対応ブランチを切ったタイミングに依りますが、 **開発作業でブランチ間を`switch`で行き来する際に、ファイルの作成/削除でやたらオーバーヘッドがかかる場合が発生します.** これにはちょっとついてゆけないと感じることがしばしばです. 上記のようにあまりバージョン管理に馴染まないものは、どのようにリポジトリを組み立てるのがベストプラクティスなのでしょうか? 1. `/trunk`、`/branches`、`/tags`と並列のフォルダで`/docs`、`/test-data`、`/resources`、`/tools`のようなものを作って管理する. 2. そもそもこのようなものは別のリポジトリを作って管理する. ※ 1. は`/trunk`、`/branches`、`/tags`と`/docs`、`/test-data`、`/resources`でフォルダ構成が異なるでしょう. お知恵がありましたらよろしくお願いいたします. 以上
回答: ※あくまで私が考える配置方法で、最適解ではありません。そのうえでお読みいただければ。 コメントにも同じく記載されていますが、「対象のデータはバージョン管理に必要か」を基準としてsvnのリポジトリに含めるかどうか決めるのがベターなのではないかと思います。 * ドキュメントはバージョンによって変わっていくのでリポジトリに含めます。ただし既存の`/trunk` `/branches` `/tags`と並列には作らず、コードと同列の扱いで保管します。ただ、ドキュメント量が多くなってくると質問に書かれている通りチェックアウト時の待ち時間が膨大になります(実際そんな管理方法をしていたことがありました...)。システム規模に依るのでドキュメントのデータ量が膨大になるのであればドキュメント専用のリポジトリを作ってもらうのも選択肢として考えてみてください。 * 顧客から渡されるテストデータはそのバージョン限り、または当該バージョン以降で使用する不変のデータと考えられます。よって、リポジトリには含めません。データサイズが大きいのがネックなので別ストレージに保管し、その保管先を書いたメモを当該バージョンに含めるのは問題ないと思います。 * フォントファイルなどのリソースファイルはシステムの一部ですし、バージョンアップによって変わっていく可能性のあるものなのでリポジトリに入れる対象でしょうか。基本的に不変のものであれば別ストレージに保存しておき、リポジトリには保管先のメモを置いたりストレージからコピーしてくるバッチファイルを書いたりすると良いかもしません。ただ、フォントくらいならCDN化を検討できないかなと思います(インターネットに接続できない環境であれば仕方ありませんが) * 開発の補助プログラムやユーティリティは、その顧客のプロダクト専用のものであればソースコードと同様にバージョン管理しても差し支えないのかなと思います。複数のプロジェクトで共通して使うユーティリティ等は別リポジトリでバージョン管理するのが適切であると思います。 ドキュメントに関してもう一つ。私が以前の勤務先で管理していたリポジトリは以下の用になっていました。 ``` /部門名 /A-system-src /trunk /branches /tags /A-system-doc /trunk /branches /tags /B-system-src /trunk /branches /tags /B-system-doc /trunk /branches /tags ``` ソースコードとドキュメントを別々のサブディレクトリにしてあるのでドキュメント側のデータが膨大になってもソース側に影響しません。ただしこの構成ではIDEに付属するバージョン管理機能はほぼ使用できなくなるので不便さはありました。 ドキュメント等はIDEで管理しないので、質問者さんの案通り`/docs`ディレクトリ等を作ってソースコード側とは別サブディレクトリにしてしまうのも良い手だとは思います。ただしバージョン管理すべきかどうかを勘案して決めたほうが良いと思います(結局ソース側とは連動しない別管理になってしまうので)