私たちは、SVNプロトコルがHTTPより優れているかどうかを評価したいと思いますが、まだフルスイッチにコミットしたくありません。SVNとHTTPプロトコルを同じリポジトリで同時に安全に使用できますか?
現在、メインのリポジトリにApacheサーバが提供されています。同じリポジトリにsvnserve.exeを安全に使用できるので、開発者のうちのいくつかがそれをテストできますか?私の最初の推測は私達ができることですが、私たちはリポジトリを壊す危険を冒すつもりはありません。
私たちは、SVNプロトコルがHTTPより優れているかどうかを評価したいと思いますが、まだフルスイッチにコミットしたくありません。SVNとHTTPプロトコルを同じリポジトリで同時に安全に使用できますか?
現在、メインのリポジトリにApacheサーバが提供されています。同じリポジトリにsvnserve.exeを安全に使用できるので、開発者のうちのいくつかがそれをテストできますか?私の最初の推測は私達ができることですが、私たちはリポジトリを壊す危険を冒すつもりはありません。
はい、可能です。公式のSVNの本は、この状況に特化した章を持っています: http://svnbook.red-bean.com/en/1.5/svn.serverconfig.multimethod.html。いくつかの落とし穴がありますが、許可の設定とはさらに関係があります。
まさにSubversionは、複数のプロトコルによる同時アクセスをサポートするように設計されており、CVSに大きな問題を引き起こしています。 http://とsvn://だけでなく、file://も使用できます(たとえば、継続的な統合ツールやその他のコミット後のフックなど、マシン上でローカルに作業する場合)https:/ /、svn + ssh://など
私の経験では、一方の方法は客観的に「他の方法よりも良い」とは証明されていませんが、それぞれには一定の利点があります。たとえば、Apacheは1つの場所でたくさんのアクセスを処理するのに非常に熟練しています。一方、Apacheをまだ使用していない場合や、SVNトラフィックを処理したくない場合は、svnserve
デーモンは軽量であり、かなりパフォーマンスが良いです。私のMacでは、launchdを使用してsvnserveをセットアップし、要求が入ったときにのみ起動するので、リポジトリのアクティビティがないときはリソースを使用しません。最も効果的なのは、実際に見られるアクセスパターンの大きな要因になります。