現在、私の会社はネットワーク共有を使用してSVNリポジトリと通信しています。本当に遅いのでSVNSERVEに切り替えたいと思います。
私の会社がファイルシステムルートを選択した主な理由は、既存のActiveDirectory認証システムを使用して簡単に保護できるようになったためです。
私が読んだことから、 Saslライブラリ を使用している限り、ActiveDirectoryでSvnServeを使用することが可能です。他の誰かがこれをやっていて、どこにも文書化されていないように見えるので、構成に関するいくつかの指針を与えることができるかどうか疑問に思っていました。
ありがとう
編集
高速サーバー上にsvnがありますが、残念ながら他の企業のファイル共有やサービスに使用されています。
HTTPプロトコルはSMBを使用したfile://よりも高速ではないと言われています。誰かがこれに関するドキュメントを持っていますか?私は、真のクライアントサーバーモデルの方がパフォーマンスが優れていると考えました。約13人の開発者とビルドサーバーが一日中コミットして更新しています。
死んだ単純なルートに行き、VisualSVNサーバーをインストールするだけです。
http://www.visualsvn.com/server/
ActiveDirectoryに参加しているサーバーにインストールします。これで、AD認証を使用したSVN over http(s)ができました。付属の便利なダンディMMCツールを使用して権限を管理します。0から約15分でデプロイされます。
File://アクセスはSVNリポジトリには推奨されておらず、管理ツールには推奨されていないことに注意してください。ファイルアクセスの問題は、すべての書き込みが正しく書き込まれていることを確認するためのサーバーが途中にないことです。したがって、できるだけ早く使用を中止してください。
Svnserve(またはApache)の方がはるかに優れていますが、同じパフォーマンスの問題が発生します。ネットワークでsmbの代わりにhttpまたはsvnプロトコルが使用されているため、パフォーマンスが向上することはありません。今日のアクセスが遅い場合でも、ネットワークやファイルシステム(またはその他の理由で遅くなっているもの)について何かをしない限り、アクセスは遅くなります。
ただし、ApacheまたはSvnserveへの移行はそれ自体で行う価値があります。
最近svnメーリングリストで言及されているように、svnserveとsaslライブラリに問題があります。問題は、svnプロトコルはプレーンテキストを許可しないが、プレーンテキスト認証はsaslauthdによってのみ許可されることです。最終結果- それは単に機能しません 、そして 既知の問題 です。
ただし、すべてが悪いわけではありません。Windowsで実行している場合は、VisualSVNサーバーをインストールするだけです。その最上位のパッケージであり、スナップイン管理を備えたWindowsサービスとして実行されるApacheインストールと、インストール中にラジオボタンを1回クリックするだけのActiveDirectory認証を提供します。リポジトリ内のディレクトリまたはファイルにACLを配置することもできます。
そうでない場合でも、Apacheの構成がより適切に文書化されており、LDAP認証(ADで機能する)をサポートしているため、Apacheをお勧めします。これを行う方法を説明するブログ投稿はたくさんあります。
Svnの代わりにhttpのパフォーマンスは遅くなりますが、サイドバイサイドでインストールし、大きなディレクトリをチェックアウト/コミットしない限り、気付かないと思います。試してみてください。SvnserveでApacheが提供するリポジトリを同時に提供できます。 (私はそれを実行する前にその主張を確認しますが)。
申し訳ありませんが、Windows認証を使用するSvnserveはありません。それでも、ここでSVNを使用している実際のプログラマーの数は非常に少ないため、SASLでSvnserveを使用し、アカウントを手動で管理しています。
SVNを実行するためにWindowsファイル共有のリスクを冒しても構わないと思っているという事実は、絶望的な状況にある必要があることを示しています。そのため、代わりにSSL over Apacheをお勧めします。ここでは、Windows認証を取得できます 。 SVNの代わりにSSLを使用していますが、十分に近いです。ここに行く:
mod_auth_sspi
をインストールし、CollabNetSubversionサーバーに付属のhttpd.conf
にセットアップします。私はHTTPSとSVNの両方を実行していますが、個人的にはSASLアカウントを手動で管理することを好みます。これにより、HTTPSよりも少し速いSVNプロトコルの速度をさらに上げることができます。
つまり、SVNリポジトリをネットワーク共有からSVNServeまたはApache/WebDAVに切り替えても、クライアントのパフォーマンスは向上しません。どちらかといえば、クライアントのパフォーマンスは低下します。
もちろん、上記は、現在リポジトリをホストしている同じサーバーでリポジトリを実行し続けることを計画していることを前提としています。 SVNリポジトリをより強力なサーバーに移動すると、パフォーマンスが向上する場合があります。
現在のサーバーが過負荷になっていないか確認しましたか? SVN以外のクライアント/ファイルもたくさん提供していますか?その場合、SVNリポジトリを専用サーバーに移動することでパフォーマンスが向上する可能性があります。 1つのサーバーに複数のリポジトリがある場合は、それらを複数のサーバーに分割することを検討してください。 (これを支援するために、必要に応じて、既存の単一リポジトリーを複数のリポジトリーに分割できます。)
ただし、実際には、既存のパフォーマンスが低い理由を理解する必要があります。まず、現在のサーバーの負荷を分析します。パフォーマンスは通常、一部のシステムリソースの容量、主にRAM、CPU、ディスクI/Oレート、ネットワークI/O容量によって制限されます。次の質問に答えてみてください。
CPUが100%に固定されていますか、それともフリーサイクルがたくさんありますか? CPU使用率は異なる場合がありますが、平均が100%またはそれに近い場合は、より多くの/より高速なCPUが必要になる場合があります。
RAMはどれくらいありますか(全体の%)?どのくらいのスワップスペースを使用していますか(ここでも、全体の%)?空きRAMが10%未満の場合は、RAMが不足している可能性があり、代わりにシステムがディスクスワップを使用するように強制されます。これによりすべてが遅くなりますが、スワッピングが限られたディスクI/OのSVNアクティビティと競合するため、さらに悪いことになります。
1秒あたりどのくらいのデータ(一括転送)をディスクとの間で移動していますか?ディスクのパフォーマンスは1秒あたり何回ですか?ディスクキューの長さはどれくらいですか?サーバーのディスクは、バルクデータ転送とシークレートに対応している必要があります。 (そうでない場合は、自分でベンチマークできます。)平均転送速度とシーク速度が最大またはそれに近い場合は、より高速なディスクを使用する必要があります。 RAIDを使用している場合は、パフォーマンスを向上させる方法でディスクを追加します。 RAIDを使用していない場合は、RAIDの使用を開始してください。
サーバーとの間で1秒あたりどのくらいのネットワークデータを転送していますか?そのレートが定格最大値の80〜90%に近づく場合(たとえば、10Mbit/s、100Mbit/s、1Gbit/s)、ネットワークリンクの制限に達している可能性があります。 (安価なNICまたは不良ドライバーの最大値は大幅に低くなる可能性があることに注意してください。リンクをベンチマークしてください。)より高速なリンクにアップグレードするか、NICドライバーがボンディング(「リンクアグリゲーション」とも呼ばれます)をサポートしているかどうかを確認してください。パフォーマンスを向上させるための「または「チャネルボンディング」)。
ご使用の環境に関するこれらの質問への回答を前提として、制限されているリソースの容量を増やしてみてください。これは、サーバーのアップグレードまたは交換、あるいはネットワークのアップグレードを意味する場合があります。
まったく同じではありませんが、Linuxサーバーにsvnリポジトリがあります。サーバーはsvnserveを実行していませんが、ユーザーはsshを介してsvnを使用できます。 LinuxサーバーはADメンバーサーバーであり、ユーザーもADから来ているため、これは非常に簡単で安全なソリューションです。