「派生」ファイルのバージョンを管理していますか?

Question

バージョン管理システムへのオンライン インターフェイスを使用することは、コードの最新バージョンの公開場所を確保する優れた方法です。たとえば、ここに LaTeX パッケージがあります (変更が実際に機能することが確認されるたびに CTAN にリリースされます)。

http://github.com/wspr/pstool/tree/master

パッケージ自体は 1 つのファイル (この場合は pstool.tex) から派生しており、このファイルが処理されると、ドキュメント、readme、インストーラー ファイル、および LaTeX で使用されるパッケージを構成する実際のファイルが生成されます。

ユーザーがこのファイルを簡単にダウンロードできるように、マスター ファイル pstool.tex だけでなく、上記のすべての派生ファイルもリポジトリ自体に含めています。これは、パッケージ ファイル pstool.sty がマスター ファイルの生成されたサブセットであるため、コミットするたびに 2 倍の変更が加えられることを意味します。

これはバージョン管理の倒錯でしょうか?

---

@ジョン・リムジャップ 良い点を指摘しました:

ダウンロード サーバーとしてバージョン管理に依存するのではなく、生成されたファイルをダウンロード用に別の場所に公開する別の方法はありますか?

実はそれがこの事件の問題の核心なのです。はい、パッケージのリリースされたバージョンは他の場所から入手できます。したがって、生成されていないファイルのみをバージョン管理する方が実際には合理的です。

一方で、 @マディールのコメントは次のとおりです。

現実に繰り返される利便性が、舞台裏で負担するコストを上回る

これは、ユーザーがバグを見つけて私がすぐに修正した場合、ユーザーはリポジトリにアクセスして、「インストール」手順を実行せずに作業を続行するために必要なファイルを取得できるという点でもかなり適切です。

そして、これがより重要な使用例だと思います 私の特定のプロジェクトのセットに対して.

Answer 1

小規模システムの ASP.NET 開発に Tortoise SVN を使用しています。ほとんどのコードは ASPX として解釈されますが、手動のコンパイル手順によって生成されるバイナリ DLL が約 12 個あります。理論的には、これらのソースコードをバージョン管理することはあまり意味がありませんが、開発環境から運用システムに (ワンクリックで) 確実に正しくミラーリングされることを確認するのに便利であることは確かです。また、災害が発生した場合には、SVN でワンクリックで前のステップにロールバックできます。

そこで私は思い切って、それらを SVN アーカイブに含めました。実際に繰り返される便利さは、舞台裏で負担するコストを上回ります。

Answer 2

リポジトリ自体に含まれるスクリプトを使用して自動的に生成されるファイルのバージョン管理は行いません。その理由は、チェックアウト後にこれらのファイルを 1 回のクリックまたはコマンドで再構築できるためです。私たちのプロジェクトでは、これをできるだけ簡単にするよう常に努めており、その結果、これらのファイルのバージョン管理が不要になります。

私が想像できるシナリオの 1 つは、出力の生成に必要なツールが利用できない可能性がある実稼働環境 (または非開発環境) で使用するために、製品の特定のリリースに「タグを付ける」場合にこれが役立つ可能性があるということです。

また、製品のリリース バージョンのアーカイブを作成およびアップロードできるビルド スクリプト内のターゲットも使用します。これは、実稼働サーバー、または製品のユーザーがダウンロードするために HTTP サーバーにアップロードできます。

Answer 3

必ずしもそうとは限りませんが、ソース管理のベスト プラクティスでは、明らかな理由から、生成されたファイルを含めないことが推奨されています。

ダウンロード サーバーとしてバージョン管理に依存するのではなく、生成されたファイルをダウンロード用に別の場所に公開する別の方法はありますか?

Answer 4

通常、派生ファイルはバージョン管理に保存すべきではありません。あなたの場合、派生ファイルを含む tarball を作成するリリース手順を構築できます。

あなたが言うように、派生ファイルをバージョン管理に保持すると、対処しなければならないノイズの量が増えるだけです。

Answer 5

場合によってはそうすることもありますが、それはどちらかというとシステム管理者タイプのユースケースであり、生成されたファイル (スクリプトから構築された DNS ゾーン ファイルなど) にはそれ自体に本質的な関心があり、リビジョン管理は監査証跡よりも線形です。分岐とタグ付けのソース管理。