2

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

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

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

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

これはバージョン管理の変質ですか?


@ Jon Limjapは良い点を挙げました:

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

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

一方、@ Madirのコメントは次のとおりです。

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

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

そして、これは私の特定のプロジェクトセットのより重要なユースケースだと思います。

4

5 に答える 5

4

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

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

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

于 2008-09-02T10:21:06.327 に答える
2

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

だから私は弾丸をかみ、それらをSVNアーカイブに含めました-実際に繰り返される便利さは、舞台裏で負担されるコストを上回ります。

于 2008-09-02T10:25:26.237 に答える
1

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

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

于 2008-09-02T10:10:44.027 に答える
1

通常、派生ファイルはバージョン管理に保存しないでください。あなたの場合、派生ファイルを含むtarballを作成するリリースプロシージャを作成できます。

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

于 2008-09-02T10:13:51.617 に答える
0

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

于 2008-09-02T10:44:50.917 に答える