私は VCS を扱ったことがないので、基本的な間違いがあれば訂正してください。
私のプロジェクトでは、Subversion を使用することを選択し、ドキュメントを読んでいます。私の理解が正しければ、リビジョン番号はチェックインごとにインクリメントされます。ただし、これには疑問が生じます。一度に複数のファイルをチェックインすることはできますか (増分は 1 つだけです)? また、たとえば、チェックインがコンパイルされない場合はどうなりますか? リビジョン番号はインクリメントされますか?
私は VCS を扱ったことがないので、基本的な間違いがあれば訂正してください。
私のプロジェクトでは、Subversion を使用することを選択し、ドキュメントを読んでいます。私の理解が正しければ、リビジョン番号はチェックインごとにインクリメントされます。ただし、これには疑問が生じます。一度に複数のファイルをチェックインすることはできますか (増分は 1 つだけです)? また、たとえば、チェックインがコンパイルされない場合はどうなりますか? リビジョン番号はインクリメントされますか?
一度に複数のファイルをチェックインすることはできますか (増分は 1 つだけです)?
はい、可能です。Subversion には変更セットがありますか?を参照してください。公式FAQより。
また、たとえば、チェックインがコンパイルされない場合はどうなりますか? リビジョン番号はインクリメントされますか?
通常、現在の状態がテスト環境でコンパイルされるかどうかを最初にテストし、コンパイルされるかどうかをチェックインします。
テストを実行するpre-commit フックを使用してこれを自動化でき、その条件でチェックインを続行できます。
はい、一度に複数のファイルをチェックインできます。これにより、リビジョンが 1 だけインクリメントされます。
2 番目の質問では、「コンパイル」という意味ではないと思います。リビジョン管理システムは、制御するコードがコンパイル可能かどうかを気にしないためです。「コミットする」という意味だと思います。その場合の答えは、Subversion コミットはアトミックであるということです。それらは完全に機能するか、完全に失敗します。複数ファイルのコミットを試みて、一部のファイルを成功させ、他のファイルを失敗させることは不可能です。コミットが失敗しても、リビジョン番号は増加しません。
Subversion コミットはトランザクションです。コミット全体が成功するか、コミット全体が失敗します。コミットが成功すると、リビジョン番号がインクリメントされます。そのため、コミット全体に含まれるファイルの数に関係なく、リビジョン番号が 1 ずつ増加します。
Subversion には、コードがコンパイルされるかどうかを知る方法がありません。したがって、壊れたコードをコミットすると、壊れたコードをコミットしますが、リビジョン番号は引き続き増加します。コミットをロールバックすることはできません (少なくとも、簡単ではなく、かなりの不便が伴います)。
ビルド サーバーが必要な場合は、JetBrains TeamCityをお勧めします。TeamCity には、「テスト済みのコミット」を実行できる VisualStudio プラグインが付属しています。つまり、コードをビルドする TeamCity ビルド サーバーにコードを送信します。ビルドが成功した場合 (その場合のみ)、TeamCity は変更を Subversion にコミットします。ビルドが失敗した場合、TeamCity は通知し、コードをコミットしません。それはうまく機能し、壊れたビルドを恥ずかしくするのを防ぐのに役立ちます:)
リビジョン番号はアトミックです。つまり、一度に 1 つずつリビジョン番号を増やして、1 つのコミットの変更全体に適用されます。
Subversion は、ビルドが成功したかどうかを判断するための特定のテクノロジ スタックに関する知識や関連付けを持っていないため、コンパイルするかどうかに関係なく、リビジョン番号が増加します。
ローカルでコンパイルしない場合、通常はコミットしません。もしそうなら、あなたは「ビルドを壊し」、チーム「キティ」にお金を入れるべきです. ;-)
一部のバージョン管理システムでは、各ファイルにリビジョン番号を使用しています。Subversion は、リポジトリ全体に対して単一のリビジョン番号を使用します。コミットを行うと、Subversion は、単一のファイル、複数のファイル、または最後のチェックアウト以降に変更されたすべてのファイルに加えた変更をコミットできます ( svn add
、svn revert
、およびのドキュメントを参照してくださいsvn commit
)。Subversion はコミットをアトミック トランザクションとして扱います。つまり、コミットするファイルの数に関係なく、すべてのファイルが 1 回の操作でコミットされ、完全に成功するか完全に失敗します (この場合、リポジトリは変更されません)。commit コマンドを発行するたびに、リポジトリ全体のリビジョン番号が増加します。
Subversion はコードがコンパイルされるかどうかを認識しないため、不正なコードのチェックインを妨げるものは何もありません。Subversion を使用して、ソース コードだけでなく、あらゆる種類のファイルを保存できるため、Subversion は、チェックインしたものの機能を検証しようとしません (テキスト ファイルでいっぱいのリポジトリを「構築」しようとしても意味がなく、サーバーがビルドシステムやコードのコンパイル方法を推測する信頼できる方法がないためです)。そうは言っても、コミットが試行されたときはいつでも、トランザクションが処理される前にスクリプトを実行するように Subversion サーバーに指示することができます (プリコミットフックと呼ばれます)。)。一部の人々は、ソース コードをビルドしようとするスクリプトでこの機能を使用します (受信した変更を含む)。スクリプトがソースをビルドできない場合、エラーが返され、Subversion はトランザクションを拒否します (ユーザー側では、コミット操作が失敗することがわかります)。自動ビルド ソース コードは、デフォルトで Subversion に組み込まれているものではありませんが、興味がある場合は追加するのはそれほど難しくありません。
詳細については、Subversion の (無料の) 公式本「Version Control with Subversion」を読むことを強くお勧めします。読みやすく、Subversion について知りたいことがほとんどすべて含まれており、多くの例が含まれています。