複数のコンピューターが共有ファイルシステムに保存されているsvnリポジトリに同時にアクセスするのは安全ですか？
私は、各Windowsクライアントマシンにローカルのワーキングセットのファイルがあり、チームの他のメンバーと定期的に同期できるアプリケーションを構築しています。サーバーの観点からは、Windows共有マウントポイント以外は何にも依存したくありません。svn file：// URLプロトコルは共有ファイルシステムをサポートしていますか、それともファイルシステムがローカルであると想定していますか？
Subversionのドキュメントには、Win9x環境でのBDBとFSFSの問題が記載されていますが、file：// URLを介して同時にアクセスされるリポジトリが、最新バージョンのWindows（またはその他のオペレーティングシステム）で安全かどうかはわかりません。
編集 私が構築しているアプリケーションはsvnを直接使用するので、安全な同時共有コラボレーション環境が可能であれば、比較的制約のある環境を構築したいと思います。
Tortoise SVNのドキュメントは、実際には強くお勧めしません。このリンクを参照してください。。
要約すると：
file：//アクセスは、ローカルのシングルユーザーアクセス、特にテストとデバッグのみを対象としています。
別の質問も似ていますが、次のように尋ねられました: パフォーマンス: Subversion プロトコルのパフォーマンス
SVN Book では、複数のユーザーに対して file:// プロトコルを使用しないことを推奨しています。
すべてのユーザーが file:// URL を介してリポジトリに直接アクセスするという単純な考えに惑わされないでください。リポジトリがネットワーク共有を介して誰でもすぐに利用できる場合でも、これは悪い考えです。ユーザーとリポジトリの間の保護層が取り除かれます。ユーザーは誤って (または意図的に) リポジトリ データベースを破損する可能性があり、検査やアップグレードのためにリポジトリをオフラインにすることが難しくなり、ファイルのアクセス許可の問題が混乱する可能性があります ( 「複数のリポジトリ アクセス方法のサポート」項を参照してください)。これは、svn+ssh:// URL を介してリポジトリにアクセスすることに対して警告する理由の 1 つでもあることに注意してください。セキュリティの観点からは、ローカル ユーザーが file:// を介してアクセスするのと実質的に同じであり、すべて同じ問題を引き起こす可能性があります。管理人が気をつけないと
技術的な観点からは、file:// プロトコルを複数のユーザーで使用することは完全に可能です。
Subversion は FSFS で独自のロック メカニズムを使用するため、標準的な svn の使用では破損は発生しません。それ以外の場合、SVN ブックは、BDB バックエンドでこの問題について言及しているように、そのような設定を避けるように明確に述べています。
しかし、本当の問題は、リポジトリ データベースへのアクセスを制限して、他の任意のツールでリポジトリ データにアクセスしないようにする方法です。
file:// を使用すると、誰もが SVN リポジトリ内の各ファイルを開き、その内容を変更することができ、確実にリポジトリが破損します。
なんと、すべてのユーザーがリポジトリ全体を削除できます!
svn ツールへのアクセスを制限することはできないため、file:// プロトコルは使用しないでください。
頭から離れて（そしてオンラインで情報を見つけることができませんでした）、file：//プロトコルをサポートするSVNクライアント（TortoiseSVNなど）を使用している場合は、正しく機能するはずです。
ただし、残念ながらドキュメントが見つかりません。file：//プロトコルとSVNに特定の問題があったことを覚えています。可能であれば、Windows共有に依存するのではなく、SVNサーバーをセットアップすることをお勧めします（ VisualSVNは非常にうまく機能し、セットアップが簡単です）。
編集： Stackoverflowでこのディスカッションを見つけました。ファイルプロトコルの使用に問題はないようです。
編集2：ニールのリンクは私がしばらく前に読んだものであり、ファイルプロトコルを思いとどまらせます。ただし、file：//プロトコルを使用することが、ソース管理を使用する場合と使用しない場合の違いを意味する場合は、少なくともそれを使用することをお勧めします。一部のソース管理は、何もないよりも優れています。
このアプローチの問題に備えていると思います。Windows CIFS (Windows ファイル共有プロトコル) には、oplocking と同時変更に関する多くの既知の問題があるため、非常に遅くなるか、安全でないか、またはその両方になります。
はるかに優れた解決策は、file:// URL を使用する代わりに実際の SVN サーバーをセットアップすることです。
そうですよ兄貴…
そこに行ったことがある。私もファイルシステムを使用して、2台のマシン間で「svnサーバー」を共有しました...私が得た唯一のものは、破損したファイルと大きな頭痛の種でした...
svn サーバー (CollabNetSubversion サーバー) をインストールし、今ではすべてがスムーズに実行されています...自分で台無しにしたときを除いて... しかし、これは別の話です....
乾杯。
アルド
Windowsでそれを行った方法は、Apacheを使用してファイルを提供することでした。 ここで は、この設定に非常に満足しています。