3

ソース管理を提供することを主な目的とするアプリケーションに取り組んでいます。私の考えは、ファイルのチェックアウトとチェックインに SVNKit を使用することです。しかし、SVNKit を使用しているときに、求めていた速度がないことに気付きました。たとえば、開発者が 3 ～ 40 個のファイルの変更を含む可能性のある ChangeRequest を作成するたびに、32 個のフォルダーに分散されたディレクトリ構造を作成する必要があります。これには約 50 秒かかります。別の例では、変更要求を作成した後、開発者は要求にファイルを追加できます。トランクからブランチに 1 つのファイルをコピーするだけでも、約 6 ～ 7 秒かかります。私の質問は、誰かがこのような経験をしたことがありますか?パフォーマンスを改善するために何をしましたか? さらに、私のアプローチは正しいですか？

注: 「http」プロトコルを使用していますが、「svn」プロトコルは使用できません。

4

3 に答える 3

1

一般的に、SVNKitはSubversionの完全なJava実装です。そして、はい、それはネイティブのものよりもはるかに遅いです。したがって、Javaのみのコードに制限されていない場合は、次のことを試してみてください。

  • ネイティブSVNCAPIを使用します。
  • SVNJavaバインディングを使用する

詳細については、http：//svnbook.red-bean.com/en/1.5/svn.developer.usingapi.html ボックス「SVNKitとjavahl」を参照してください。

また、注意してください...プロトコルは（実際には）パフォーマンスにほとんど影響を与えません。

于 2010-04-19T05:33:48.807 に答える
0

詳細はわかりませんが（どのようなファイルで、個々のファイルの大きさはどれくらいですか？）、SVNはそれほど遅くはありません。

ここで使用し、正常に動作します。

興味があるのですが、SVN サーバーはどこでホストされていますか? ネットワークの内外? ネットワークが原因で遅くなる可能性がありますか？

于 2010-04-19T05:29:20.223 に答える
-2

これは本当に多くの情報ではなく、ほとんどが噂として伝えられています。

  • SVNには、ユーザー数が3桁または4桁になるため、深刻なスケーリングの問題があります。人々はコピーを引っ張る傾向があり、いくつかの貧弱なスケーリングオプションがあります。
  • 商用製品であるPerfForceには、スケーリングの問題はありません。
  • GITにはスケーリングの問題はありませんが、破損しやすいです。
  • Mercurialはうまく機能し、スケーリングもうまくいきます。次に、誰かの高馬が現れ、非常に大きなファイルをチェックインする際に吠えます。CR/LFの問題もあります。

これはすべて噂です。

于 2010-04-19T05:34:24.213 に答える