SVNバイナリの競合の解決

Question

私は、他の数人の開発者と一緒に取り組んでいるプロジェクトにsvnを使用しています。 Svnはソース管理に対しては正常に機能しますが、dllをコミットするときにすべての方法で競合が発生します。

競合を解決するとき（差分プログラムがバイナリファイルを処理できないためにDLLが削除される）、コミットするために再構築する必要があります。このような競合をどのように解決するつもりですか？

編集：

プロジェクトはゲームmodであり、非プログラマーは最新のビルドにアクセスする必要があるため、dllは別のsvnフォルダーにあります。

Answer 1

他の回答で述べたように、最初に生成されたdllをバージョン管理するべきではありません。しかし、本当にバージョン管理する がある場合は、dllファイルを削除するdiffツールを使用せずに競合を解決できます。

競合するすべてのファイルについて、Subversionは作業コピーに3つのバージョン管理外のファイルを追加します。

filename.mine

これは、作業コピーを更新する前に作業コピーに存在していたファイルです。つまり、競合マーカーはありません。このファイルには最新の変更のみが含まれています。 （Subversionがファイルをマージできないと判断した場合、.mineファイルは作成されません。作業ファイルと同一であるためです。）

filename.rOLDREV

これは、作業コピーを更新する前のBASEリビジョンであったファイルです。つまり、最新の編集を行う前にチェックアウトしたファイルです。

filename.rNEWREV

これは、作業コピーを更新したときにSubversionクライアントがサーバーから受信したファイルです。このファイルは、リポジトリの最新リビジョンに対応しています。

OLDREVは.svnディレクトリ内のファイルのリビジョン番号、NEWREVはリポジトリHEADのリビジョン番号です。

今、このような競合を解決するには、不要な追加ファイルを削除します。

• 独自のdllを保持する場合は、ファイルfilename.rOLDREV、filename.rNEWREVを削除します
• dllをリポジトリから保持する場合は、ファイルfilename.rOLDREVおよびfilename.mineを削除してから、filename.rNEWREVをファイル名にコピーします

その後、実行

svn resolved filename

競合を自分で解決したことをSubversionに伝えます。

Answer 2

ビルドしているDLLの場合（ソースを持たない外部のDLLではなく）、ソースはバイナリではなくソース管理内にある必要があります。

特定のリポジトリに含めたくない場合は、svn：externalとして含めることができます。

Answer 3

通常、独自のコンパイル済みDLLをソース管理に保存することはまったくありません。これを行う必要がある特定の理由がありますか？

開発環境をセットアップして、誰でもプロジェクトコンポーネントを他のユーザーとは独立してビルドできるようにしました。このようにして、私のソース管理システムにあるのは、私の source コードだけです。これには多くの利点があります：

• DLLまたはEXEをチェックインする際のバイナリファイルの競合を回避します
• ソース管理システムによって追跡されるデータの量ははるかに少ないため、高速になります
• 開発者が常に独自のDLLを構築する場合、開発者は自分が持っているソースコードがコンパイルされたファイルと一致することを合理的に確信できます。他の誰かが作成したものを使用している場合、確信が持てません。

コメントで述べたように、特に実際にソースのソースを持っていない場合、ソース管理システムにサードパーティのDLLを保存することは完全に合理的です。また、ソース管理のさまざまなオープンソースライブラリの配布ファイル（ .tar.gz など）を保存し、 Makefile のシステム全体を使用するプロジェクトにも取り組みました。すべてをビルドするターゲットの一部としてこれらのライブラリをビルドしました。

Answer 4

バイナリファイルの場合、ほとんどの場合、いずれかのバージョンを受け入れます。たとえば、問題のファイルが実行可能ツールである場合、通常、1つのバージョンが他のバージョンよりも新しい場合があり、それが使用したい場合があります。

マージ元のブランチにあるバージョンを受け入れるには、次を使用します。

svn resolve --accept=theirs-full path/to/filename

以前に現在のブランチにあったバージョンを受け入れるには、次を使用します：

svn resolve --accept=mine-full path/to/filename

SVNは、警告付きで theirs-full の使用を拒否することがあります：

svn：警告：W195024：競合するパスに対して適用できない競合解決オプション

SVNはマージに関してはたわごとだからです。その場合、受け入れられた回答 https://stackoverflow.com/a/410767/2279059、やろうとしていることを目的としたコマンドラインオプションを使用するのではなく。両方のファイルが同一であることがわかっている場合（ただし、SVNは既に述べた理由により、まだ競合としてマークしています）、

を使用することもできます

svn resolve --accept=working path/to/filename

これは、同一のファイルの場合、他のすべてのコマンドと事実上同じですが、SVNは実行をward病に拒否しません。これは理にかなっていますか？いいえ、そうではありません。それに対処する。

Answer 5

バージョン管理にもバイナリを含めることは合理的です：

• バイナリのみを使用するユーザーの再構築の手間を回避します。

• リリース時にバイナリが固定されます。

これを機能させるには、バイナリが常にソースに対応している必要があります。 したがって、ソースをマージした場合、ソースからバイナリを再構築する必要があります。 マージされたバージョンからバイナリの1つを選択しても実行されません。

Answer 6

dllの svn：mime-type プロパティが application / octet-stream またはその他の非テキストタイプに設定されていることを確認します。

svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll

競合が発生した場合、実際には競合を解決する必要があります。

ファイルコンテンツタイプ」の章。

Answer 7

したがって、*。dllを別のフォルダーに入れると、次のように簡単になります。

1. 変更をビルドする直前に* .dllフォルダーを更新すると、信頼できる場合は、同僚がコンパイル可能なソースコードのみをコミットすることを信頼できます。 （競合が発生した場合（最新のリビジョンに更新する前に何かを変更したときの、その時点での障害））
2. ビルドを行います。
3. 結果を直接コミットします。

別の方法：

結果がどうであれ満足するまで、ディレクトリ内のパスにビルドせず、外部のどこかにビルドします。

次に、次の手順を実行します。

1. dllsフォルダーの作業コピーを更新します（競合が発生した場合は、その障害を解決し、＆quot; keep theirs＆quot;によって競合を解決します）
2. 作業用.dllを作業用コピーにコピーします
3. 新しいリビジョンをコミットすることを同僚に通知します（この手順は省略できます）
4. 競合がある場合は作業をコミットしてください。それは彼らのせいです。

次の2つの可能性があります。

5a。あなたは非常に忌まわしい人物であり、私を維持することで問題を解決します。

5b。作業する必要があります...ログファイルを読んで、作業をフォルダにコピーしてコミットを押すのに必要な短い時間にコミットしたユーザーを見つけます。その同僚と話してください。さらなる行動に同意する。