svn - バイナリを SVN に保存することは許容されますか?

Question

ランタイムプロジェクトのバイナリファイルを共有したいと考えています。そのため、すべてのチームメンバーが現在の作業バージョンを使用できます。実行時バイナリを SVN に保存することは許容されますか?

score 27 · Accepted Answer

バイナリをバージョン管理システムに保存する一般的な理由は次の 2 つです (2009 年に作成)。

外部のサードパーティライブラリを保存します。
通常はこれらを Maven リポジトリに保存しますが、SVN に保存することで、必要なすべての参照を 1 つだけ持つことができます: ソースを取得し、それらのソースをコンパイルするために必要なライブラリを取得します。すべてが 1 つのリポジトリから取得されます。

（ 2017年にivorujavaboyが指摘したように：「現在これを行う唯一の正当な理由は、決して変更されないSTATICライブラリがある場合であり、これは非常にまれなケースです」）

より迅速な展開のために配送を保管します。
通常、配信 (本番環境にデプロイするためにビルドする実行可能ファイル) はオンデマンドでビルドされます。
しかし、多くのプリプロダクション環境があり、多くの配信がある場合、アセンブリ、統合、認証、プリプロダクションプラットフォーム用にそれらを構築するコストが高くなる可能性があります。
解決策は、それらを一度ビルドし、SVN の配信セクションに保存して、別の環境で直接使用することです。
注:
これは開発要素にも当てはまります。900 個の POJO ファイルを (XML バインディングによって) 生成するJaxbプロセスがあり、その開発セットを複数の環境でダウンロードする必要がある場合は、900 個ではなく 1 つの圧縮ファイルコピートランザクションが必要になる場合があります。もの。

そうです、「SVNにランタイムバイナリを保存することは受け入れられる/良いことです」...正しい理由からです。

そうは言っても：

Wim Coenenは、欠点(悪い習慣、遅い、ソースと保存された配信の不一致)について正しく言及しています。
Vladimir は、配信参照(Nexus、または Vladimir が言及しているように、Apache ivy )の使用を推奨しています。
RogerVは、前述の配信参照(彼の場合は Nexus)を使用する利点を示しています。

score 22 · Accepted Answer

いいえ、ソースコードの隣にバイナリを保存しないでください (欠点を相殺する正当な理由がない限り)。

短所:

大規模なプロジェクトでの悪いビルド慣行を助長します。ベストプラクティスは、ビルドを完全に自動化することです。バイナリをコミットすると、それを無視できます:「変更された部分のビルドを手動で行うだけです」:-(
遅い更新とコミット
ソースコードを変更するが、対応するバイナリを変更しないコミットは、開発者の間で混乱を引き起こします。不一致があることをどのように検出しますか?
svn updateバイナリのタイムスタンプを更新し、バイナリがソースコードの変更よりも新しいと誤って判断するビルドツールを混乱させます。
svn updateとのバイナリで疑似競合を引き起こしますsvn merge
リポジトリでより多くのディスク領域を使用します。(これは、プロジェクトによっては無視できる場合があります。)

一般に、他のバージョン管理されたリソースから決定論的な方法で自動的に生成されたものをコミットすることは避けてください。冗長性なし -> 不整合の可能性なし。

代わりに、継続的インテグレーションサーバーを使用して、各コミットで自動的に再構築 (およびテストを実行) します。必要に応じて、このビルドサーバーにバイナリをどこか (SVN の外) に公開させます。

これは、これを絶対的なルールとして採用したり、すべてのバイナリを回避したりする必要があるという意味ではありません。必ず、ビルドツールとサードパーティのクローズドソースバイナリをプロジェクト内に配置してください。そして、それが理にかなっている場合は例外を作ります。理想的には、新しい開発者は、環境のセットアップに 1 日か 2 日を費やすことなく、チェックアウトを実行してすぐにビルドスクリプトを起動できる必要があります。

score 18 · Accepted Answer

それがあなたのチームの生活を楽にするなら、そうしてください。動作する開発環境のセットアップにかかる時間が短縮される場合は、それを選択してください。

score 9 · Accepted Answer

多くの人がすでに言っているように、それは受け入れられます。

はい、1 つの場所からすべてを手元に置いておくと便利です。たとえば、正しい依存関係を持つバイナリ形式の古いタグをチェックアウトできます。

しかし、特にバックアップの目的には適していません。すべてのバイナリ (および依存関係の一部) を SVN に保存し、プロジェクトの成長に合わせてバイナリセクションを保存しました。

残念ながら、svnadmin dumpすべてをダンプするだけです。除外するリポジトリのパスを指定することはできません。したがって、バックアップ (および svn サーバーのアップグレード) は非常に苦痛になりました!

私たちの場合、それらのバイナリがもう役に立たなくなったのはそれほど長くないということを追加すると、同様のケースで再びそれを行うことはないと確信しています（ただし、小規模なプロジェクトの場合は行います）。

そのため、それを行う前によく考え、どれだけ大きく成長できるか、他に何が起こるかを予測することをお勧めします.

score 8 · Accepted Answer

この目的のためではありません。FTP や Web サーバーなどの外部ファイルストアを使用する必要があります。このようにして、最初に SVN でそのリビジョンに更新することなく、ランタイムバイナリの特定のバージョンを簡単にダウンロードできます。

score 6 · Accepted Answer

Subversion ディレクトリにライブラリが表示されるたびに、次の質問をします。

それはどのバージョンですか？（通常、持っている場合と持っaxis.jarていない場合がありますaxis-1.4.jar）
なぜ含まれていたのですか？(特に、依存関係の依存関係ではトリッキーです)

依存関係管理システムを導入していない場合、通常、両方の質問に答えることはできません。そしてジャー地獄への第一歩です。

イントラネットリポジトリを備えたApache Ivy (他の人は Maven に誓うかもしれません)をお勧めします。Ivy を使用することで、ライブラリを SVN に保存する必要がなくなり、上記の質問にいつでも答えることができました。

score 5 · Accepted Answer

はい、保管してください。

以前は、顧客に提供したバイナリを SVN リポジトリに保存して追跡していました。

また、バイナリを SVN (またはソース管理) に格納する別の用途として、ビルド時間を節約するためにプロジェクトをビルドしたくない社内の他のチームに内部ユーティリティモジュールを提供する場合があります。私はそれが一般的なやり方だと信じています。

しかし、Eclipse の .classpath および .project ファイル (ワークスペース関連の設定) を保存することは決して許可されませんでした。

score 3 · Accepted Answer

私たちのJava.jarファイルビルドは、svnにチェックインしていた.jarファイルの依存関係にバインドされていました。これの多くは実際には冗長でしたが、私たちが作成したすべてのJavaアプリのビルドに、QAを受けたライブラリが正確に含まれるようにしたかったのです。

しかし、このアプローチで私を本当に苛立たせたのは、リポジトリへのリモート接続と同期を開始したときでした。すべてのバイナリライブラリを解き放つには、永遠に時間がかかります。

それ以来、私たちはその慣習を放棄し、Mavenを使用してライブラリの依存関係を管理しています-まだantで構築しているプロジェクトでも。svnにチェックインされるバイナリはもうありません。この戦略の転換により、人生はいくつかの面ではるかに良くなっています。また、必要なライブラリ依存関係のバージョンを厳密に制御できます。

私たちの.NETビルドでは、私の開発者の1人が、すべての依存関係管理に関してMavenのように大部分が機能するソリューションを考案し、そこでもほぼ同じメリットを達成しています。

score 3 · Accepted Answer

Javaで開発している場合は、ローカルリポジトリを設定し、 mavenやivy + antなどのツールを使用してアクセスできます。

ローカルビルドアーティファクトの更新は、社内の他のユーザーが使用できるようになっているため、ローカルリポジトリにアップロードして戻すことができます。

他の開発環境では、上記のようなツールが利用できるかどうかわかりません。私はそれらをSVNに入れて、それで済ます傾向があります。

私は通常、サードパーティのライブラリを保存するために別のリポジトリを使用して、それらを通常の開発リポジトリから除外し、ビルドファイルでプロジェクトのベースフォルダに対して予想される場所にそれらをロードします。

実際、私は2つのリポジトリを使用しています。1つはプロジェクトのビルドに必要な最小限のファイル（jar、libファイルなど）用で、もう1つは通常tar.bz2を保存するサードパーティパッケージ全体（ソース、ドキュメントなどを含む）用です。

そうすれば、必要なものを最小限に抑えたい場合は、最初のリポジトリを取得し、何が起こっているのか、またはサードパーティのパッケージの使用方法を理解する必要がある場合は、ものをプルし始めることができます2番目のリポジトリから。

これは理想的なソリューションではありませんが、かなりうまく機能します。

svnがバイナリファイルを処理する方法についての詳細は次のとおりです。

score 1 · Accepted Answer

誰もがビルドできるわけではないバイナリを保存します。私は Verilog と VHDL でチップを設計していますが、ソフトウェアチームにはそれらのツールがありません。そのため、出力バイナリを SCM に保存します。

score 1 · Accepted Answer

バイナリを SVN リポジトリに保存することはまったく問題なく、受け入れられます。補足として、ビルドアーティファクトをリポジトリに保存する理由がわかりません (そうするとは言っていません)。

score 1 · Accepted Answer

簡単にアクセスできるように、ビルドおよび継続的インテグレーションシステムで最新の作業バージョンを処理できるように、それらを FTP、Web、またはファイル共有に自動的にコピーします。

ビルドアーティファクトを自動的に処理する CI システムに投資したほうがよいでしょう。私自身ジェットブレインの TeamCity が大好きですが、他にもあります。このようにして、完全に自動で処理できます。

score 1 · Accepted Answer

バージョン管理下でバイナリを保存することは、おそらくバージョン管理の目的を無効にしています。HTTP/FTP を使用することをお勧めします。https: //stackoverflow.com/questions/104453/version-control-for-binaries にある SO に関するこのディスカッションは役に立つかもしれません!

score -2 · Accepted Answer

少なくともバイナリをSVNに保存します。これにより、特定のバージョンのバイナリにすばやく戻り、バグが発生しているかどうかを確認し、プロジェクト全体をチェックするのではなく、バグが発生したバージョンを追跡できます。、特定のプロジェクト関連および環境設定をすべてセットアップしてから、コンパイルします。

score -4 · Accepted Answer

-4

この件に関しては賛否両論ありますが、私はそう言います。

于 2009-02-10T08:13:45.853 に答える

svn - バイナリを SVN に保存することは許容されますか?

15 に答える 15

Related

Reference