SVNのbinとobjのフォルダをチェックしないとなぜか

Question

これは非常に基本的な質問ですが、私はその答えを知りたいと思っています。ソース管理にSubversion（SVN）を使用していますが、すべてのファイルをチェックインしていますが、クライアントはbinとobjフォルダのチェックを避けるためにSVNでルールを作成するように求めました。
binとobjのフォルダをチェックしないのはなぜですか？

クライアントはまた、ソリューションファイルをリポジトリフォルダの外に保存するように求めました。何故ですか？

Answer 1

一時ファイルはSVNに追加しないでください。一時ファイルです。 objディレクトリ全体は、ビルド処理中に作成されたファイルで構成され、破棄されます。 （確かに、ソースファイルが変更されていないときにキャッシュのように再利用されるものもあるため、ディスク上に残りますが、それが各ビルド後に削除されない唯一の理由です）。

binディレクトリはわずかに異なります。 SVNにバイナリファイルを追加しても構いません。アイコンやイメージファイルの場合は既にそれを行っているはずです。ビルドされたバイナリも追加する人もいます。これは、設定管理プロセスに依存する決定であり、「間違った」答えはありません。ただし、binディレクトリに追加したくない他のファイルでいっぱいになることがあります。 .netアプリケーションをビルドしている場合、プロジェクトの一部ではない依存ディレクトリがbinディレクトリにコピーされます。それらを追加するだけで、あなたのリポジトリが膨らんで利益が得られません。同様に、.pdbデバッグシンボルファイルなどのbinには、サポートバイナリがあります。これらは本当に必要なものでもありません。

ソリューションファイルの場合、.slnファイルは1つ以上のプロジェクトファイルの単なるラッパーであるため、チェックインしないと問題は解りません。ビジュアルスタジオプロジェクトを新しいものとして構築するために厳密に必要とされないものは、必要に応じて作成されます。私はあなたのユーザーがそれぞれのプロジェクトごとに異なったプロジェクトグループを持つ独自の.slnファイルを作成するかもしれないと思います。これはチェックインを防止する理由になりますので、各ユーザーはお互いのカスタムファイルを上書きしません（ただし、ユーザーがsvnに格納されているファイルの変更を防ぐ方法はあります）。

あなたの設定戦略では、svnにバイナリを追加する必要はありません。どの場合には、これを防ぐために非常に良いアイデアは、誤ってプリコミットフックで起こっている。また、これらの除外をクライアント側のグローバル無視に追加して、ユーザーが最初にこれらのファイルを追加しようとするのを防ぐことをお勧めします。

Answer 2

"should not"は誰にも適用されません。しかし一般的に：

1）コードから生成できるバイナリはチェックしないでください。

2）SVNはソースコードのバージョン管理システムであり、バイナリを考慮して設計されていません。はい、SVNやその他のVCSはバイナリを扱うことができますが、特に目的地1の後ではありません）

3）これらはソースコードによって生成されるため、めったに変化しない。頻繁に変化するバイナリはVCSに課税され、VCSはバイナリを適切に処理できないため、diff（デルタ）はソースコードの場合ほど効率的ではないため、バイナリの変更ごとに多くを保存する傾向があります。

解決策（.sln）ファイルには、必ずしも必要ではないが、リポジトリにチェックインするのが理想的です。しかし、すべてではないにしても、.NETプロジェクトはVisual Studioベースでビルド目的であっても、.slnファイルを使用すると、csproj（または他のプロジェクト）ファイルではなくslnファイルでmsbuildを呼び出すことができます。適切な依存関係のコンパイル、並列コンパイルなどの他の利点が得られます。

Answer 3

チェックインするたびに、再コンパイルされた出力の変更をリマイングするように、実際にユーザー固有のファイルや生成された出力ファイルをチェックインするべきではありません。 binとobjと.suo（.slnではなく）を開始点として無視することをお勧めします。これはコンパイル時に再作成され、その後、ユーザー固有のものやすべてのビルドで再生成されるものは無視されます。