複数のユーザーがファイルベースの SVN リポジトリにアクセスして多くのことを同時にコミットする場合、SVN はデータの整合性を保証できますか? もしそうなら、どのように?または、マルチユーザーの状況で使用する必要がある提供方法ではない場合は?
3 に答える
Subversionの本から:
Subversion リポジトリは、file:// スキームを持つ URL を使用して、リポジトリが存在する同じマシン上で実行されているクライアントから同時にアクセスできます。しかし、通常の Subversion のセットアップでは、単一のサーバー マシンが、オフィス全体、またはおそらく世界中のコンピューター上のクライアントからアクセスされます。
file://
このスキームにはいくつかの問題があります。
- 同じサーバー上にある必要があります。リポジトリを Windows 共有または NFS ドライブに置き、共有をマウントして
file://
スキームを使用する人がいます。これは機能しません。file://
アクセススキームが機能するには、同じマシン上にある必要があります。 - 安全ではありません。これが最大の問題です。すべてのユーザーは、リポジトリ内のファイルに対する読み取り/書き込み権限を持っている必要があります。つまり、誰かがリポジトリを削除したり、Subversion の背後でファイルを操作したりできます。
- セットアップはそれほど難しくありません
svn://
。http://
私は自分の個人的なバージョン管理システムとして Subversion を使用しており、svn://
スキームを使用しています。Subversion withhttp://
は少し複雑ですが、約 1 時間で確実に実行できます。
私の過去の経験を共有するだけです。
私の会社には、SVN でホストされているプロジェクトがありました。当初、開発チームは file:// プロトコルを使用して SMB 共有ボリューム上のリポジトリにアクセスしていました。正直なところ、うまく機能しているようです。しかし、パフォーマンスは単にひどいです。私がひどいと言うとき、それは更新/コミットに数分を費やすようなものです. さらに、さまざまなソースまたは参照から同様のステートメントを見ることができると思います: file:// プロトコルは、ローカル マシンでの単一ユーザー アクセスのみを目的としています。
プロジェクトに参加するとすぐに、マルチユーザー アクセスのアドホック戦略に svnserve を使用するように変更します (個人的には、私が管理する他の svn リポジトリには http を使用します)。すぐにパフォーマンスが大幅に向上しました。セットアップのための余分な時間は、わずか 2 分です (コンソール モードで svnserve を起動し、実行したままにしておくことができるサーバーがあるため)。svnserve/apache を実行するマシンを実際に手配できない場合を除き、マルチユーザー アクセスのために file:// プロトコルに固執する理由がわかりません。
Subversionコミットは、アトミックになるように設計されています。したがって、同じリビジョン番号を同時にコミットする複数のユーザーは不可能です。転覆の本から:
svn commit操作は、単一のアトミックトランザクションとして任意の数のファイルとディレクトリへの変更を公開します。作業コピーでは、ファイルの内容を変更できます。ファイルとディレクトリの作成、削除、名前の変更、およびコピー。次に、変更の完全なセットをアトミックトランザクションとしてコミットします。
アトミックトランザクションとは、単にこれを意味します。つまり、すべての変更がリポジトリで行われるか、まったく行われないかのいずれかです。Subversionは、プログラムのクラッシュ、システムのクラッシュ、ネットワークの問題、および他のユーザーのアクションに直面しても、この原子性を維持しようとします。
リポジトリがコミットを受け入れるたびに、これにより、リビジョンと呼ばれるファイルシステムツリーの新しい状態が作成されます。各リビジョンには、前のリビジョンの番号より1つ大きい固有の自然数が割り当てられます。新しく作成されたリポジトリの最初のリビジョンには0の番号が付けられ、空のルートディレクトリのみで構成されます。