2

トランクとそのトランクからのブランチ A があります。

バイナリ ファイルをリビジョン A に 2 回更新し、次にリビジョン B に更新します。

最初にリビジョン B をマージし、次にリビジョン A を svn マージする場合、バイナリ ファイルの内容によって競合が発生する必要がありますか?

競合が必須の場合は、手動で処理できます。それ以外の場合、このマージ ケースでバイナリ ファイルを処理する方法を提案できる人はいますか?

4

1 に答える 1

4

これを処理するには、次の 2 つの方法があります。

リポジトリにバイナリ ファイルを保存しない

多くのサイトでは、ビルドされたアーティファクトを Subversion リポジトリに保存していますが、これはあまり良い考えではありません。それらは多くのスペースを取り、通常は非常に短い貯蔵寿命を持っています. Subversion リポジトリは簡単に消去できないため、急速に大きくなる傾向があります。ほぼ 1 テラバイトのスペースを占めていた Subversion リポジトリが、バイナリ クラフトを削除したときに数ギガバイトに縮小されたのを見てきました。

とにかく、これらのバイナリはそれほど簡単に取得できるわけではありません。それらを本当に必要としている人 (テストや展開を行っている人など) は、コンピューターに Subversion をインストールし、Subversion を入手する方法を学ばなければなりません。また、これらのファイルのさまざまなバージョンを持つ本当の目的はありません。彼らの歴史が開発者にとってそれほど啓発的なものであることはめったにありません。

ビルドされたアーティファクトをリリース リポジトリに保存することをお勧めします。ArtifactoryとJenkinsの組み合わせを使用します。Maven を使用していないときでも、Maven リポジトリを使用しました。私は Ant と Ivy でそれらを使用しており、C/C++ を使用していた場所でも使用しています。これにより、あるプロジェクトが生成し、別のプロジェクトが必要とする可能性のある成果物を共有できます。

svn:mime-typeバイナリ ファイルでプロパティを使用する

バイナリ ファイルはソースであるため、保存しなければならない場合があります。たとえば、GIF や JPG などです。この場合、svn:mime-typeそのファイルで Subversion を使用できます。これにより、Subversion が最初からバイナリ ファイルをマージしようとするのを防ぎます。

マージを実行し、バイナリ ファイルに競合があるとどうなりますか? このファイルの現在のバージョンを保持するという意味を受け入れるか、このバイナリ ファイルの現在のバージョンを他のブランチのバージョンに置き換えるという意味を受け入れることができます。これにより、マージ/解決プロセスが簡素化されます。

于 2012-08-31T13:43:27.963 に答える