バージョン管理のバージョン固有ファイル

Question

V1.0、V1.1、およびV1.2の複数のリリースバージョンがあるアプリケーションを想像してみてください。

たとえば、ユーザーマニュアル、機能テストスイート、またはいくつかの技術文書など、バージョン固有の1つ以上の関連ファイルを想像してみてください。理想的には、これらのファイルはアプリケーション自体と一緒にバージョンにチェックされるので、特定のバージョンに関連するすべてのファイルの表示やチェックアウト（例えば、機能テストを連続ビルドの一部として実行するなど）が容易です。

問題は、コードが存在しない場合でも、これらのファイルを更新する必要があります。たとえば、まだそのバージョンを使用している顧客のために修正したいV1.0ユーザーマニュアルのエラーを発見するかもしれません。あるいは、V1.2の機能テストの適用範囲を改善して、顧客が行う前にそのバージョンのバグを発見したいかもしれません。それに応じてこれらのファイルを変更したら、それらをバージョン管理にどのようにコミットしますか？私たちは、新しいバージョンのソフトウェアをリリースするつもりはなく、新しいバージョンのファイルだけをリリースしています。

FWIW、私たちはSVNを使用しています。

Answer 1

本当に問題はありません。

あなたは好きなだけ頻繁にコミットします。あなたが話しているのは、与えられた文書の異なるリビジョンをダウンして、それらを単一の「リリース」に凝縮することです。どのようにビルドするかによって、これを行うことは可能です。特定のものを特定のバージョンに更新することができます（少なくともSVNでは可能ですが、他のシステム[Visual Source Safe（神の助けを借りてください）]）を話すことはできません）。

あなたが使用しているSVNの場合は、「タグ付け」機能にも興味があります。

Answer 2

新しいバージョンをリリースしたときにプロジェクトに関連するすべてのもの（ドキュメント、機能テスト）がコピー（分岐）された場合は、ブランチ上で必要なものを更新するだけです。

通常、これはトランクからのマージによって行われますが、変更がそのバージョンに固有のものでない場合があります。