バージョン管理のベスト プラクティスを作成して従おうとしていますが、Subversion のアトミック コミットへの参照に出会いました。このアクションについて聞いたことがないので、いくつか質問があります。
- その目的は何ですか?
- いつ使用する必要がありますか?
- 通常のコミットとどう違うのですか?
- TortoiseSVNユーザーは利用できますか? もしそうなら、どのように?
バージョン管理のベスト プラクティスを作成して従おうとしていますが、Subversion のアトミック コミットへの参照に出会いました。このアクションについて聞いたことがないので、いくつか質問があります。
アトミック コミット用の特別なコマンドはありません。Subversion のすべてのコミットはアトミックです。
これは、(任意の数のファイルの) すべてのコミットが全体として成功または失敗することを意味します。
コミットされたファイルの一部のみがリポジトリに作成され、他のファイルが作成されないということはありません (たとえば、コミット操作の途中でエラーが発生したか、ファイルの 1 つで競合が発生したため)。
これは、「通常の」Subversion 機能に基づいているため、TortoiseSVN の場合と同じです。
以下は、 Subversion bookからの抜粋です。
svn commit 操作は、任意の数のファイルとディレクトリへの変更を単一のアトミック トランザクションとして発行します。作業コピーでは、ファイルの内容を変更できます。ファイルとディレクトリの作成、削除、名前変更、およびコピー。次に、変更の完全なセットをアトミック トランザクションとしてコミットします。
アトミック トランザクションとは、単にこれを意味します。すべての変更がリポジトリで発生するか、まったく発生しないかのいずれかです。Subversion は、プログラムのクラッシュ、システムのクラッシュ、ネットワークの問題、および他のユーザーのアクションに直面しても、この原子性を維持しようとします。
アイデアは、あるファイルへの変更は通常、別のファイルの変更に関連しているという単純なものです。一部の古いバージョン管理システムは、1 回のコミットで複数のファイルを実際に処理しなかったか (いわゆる「アトミック コミット」として)、処理が不十分でした。
このために特別なことをする必要はありません。それが Subversion の仕組みです。しかし、Subversion を使用すると、一度に 1 つのファイルをチェックインするか、変更されたすべてのファイルを一度にチェックインするか、またはその間の任意の場所でチェックインするかを選択できます。
複数のファイルを 1 つのコミットとして実行するという考え方は、一般的に言えば、特定のバージョンでリポジトリをチェックアウトできるようにすることであり、少なくともコンパイルして実行することができます。これはチームで重要です。実際には、これは 100% 真実ではないかもしれませんが、指針となる原則は健全です。
したがって、1 つのファイルを実行する場合でも、一度にすべての変更を行う場合でも、チェックインしている間の何かを行う場合でも、1 つのコミットとして意味があるはずです。バグを修正して 8 つのファイルを変更する必要がある場合のように、8 つのファイルすべてを 1 つのコミットとしてチェックインし、どのバグをどのように修正したかを示すメッセージを付けます。問題が発生した場合でも、後でロールアウトしやすくなります。
この場合の「アトミック」とは、アトミック操作を指します。ここで適切な定義を見つけることができます: http://en.wikipedia.org/wiki/Atomic_operation
SVN のすべてのコミットは自動的にアトミックであるため、コミットを行う場所ならどこでも無料で取得できます。
アトミック コミットの利点を知りたい場合は、ブランチをディスク上のトランクにマージすることを想像してください。午前中に開始し、昼食後、すべてがコンパイルされ、すべての単体テストが正常に実行されます。次に、そのマージ中に変更された 200 以上のファイルをコミットします。
SVN では、コミットが成功して 200 以上のファイルすべてが一度にコミットされるか、コミットが失敗してリポジトリにまったく変更が加えられませんでした。(これについては、これ以上言うことはありません。これは、常にそうあるべきだった方法です。)
アトミック コミットを持たない CVS では、誰かがネットワーク ケーブルにつまずいたため、150 ファイルの後でコミットが中断され、残りの 50 以上のファイルがコミットされず、リポジトリが中間状態のままになることがあります。あなたがネットワーク ケーブルを差し込もうとしているときに、チームの他の誰かが別の一連の変更をチェックインします。その変更のセットは、既にチェックインしたものとは切り離されているため、他の人のコミットは成功します。ただし、変更には互換性がありません。現在、チームは、テストに合格するどころか、コンパイルすらされていないコードを含むリポジトリで立ち往生しています。さらに悪いことに、2 人のチーム マネージャーは、互換性のない変更を可能な限り迅速に修正して、残りのチーム メンバーが Quake のプレイをやめて仕事に戻ることができるように、あなたの首を絞めています。
驚くべきことに、そのようなシナリオは見かけほどありそうにありません。私は何度かそこに行って、ひどいシャツのコレクションを手に入れました。
アトミック コミットの真の使用法を理解するには、継続的インテグレーションに関する次の記事をお読みください。
http://en.wikipedia.org/wiki/Continuous_integration
使用は、統合の問題が発生した場合に、特定の開発者のすべての変更を確実に元に戻すことができるようにすることです。これは、リポジトリ内のコードの整合性を維持する上で非常に強力な機能です。