ポイント #2: HTTP ブラウジングを忘れてください。それはほんの少しのボーナスです。Fisheye、ViewVC、または (私のお気に入りの) Sventonなどの必要性を置き換えるものではありません。
Subversion サーバーに Apache の http を使用することには、いくつかの欠点があります。
次に、利点があります。
- 通常はファイアウォールによってブロックされない標準ポート (80) を使用します。
- LDAPおよびActive Directoryと統合可能
- 更新とチェックアウト (ユーザーパスワードを含む) を暗号化するHTTPSを使用できます。
- 複数のリポジトリで同じ Apache httpd インスタンスを使用できます。では
svnserve、インスタンスごとに 1 つのリポジトリしか実行できません。1 つのシステムに複数のリポジトリがある場合はsvnserve、非標準ポートで各プロセスを実行する必要があります。
私の個人的な見解: 企業環境を実行している場合、HTTP または HTTPS プロトコルを使用する利点は欠点を上回ります。あなたが小さなレポジトリとあなたとあなたの友人について話しているのであれば、svnserveオーバーヘッドが少なく、セットアップが簡単なため、私は単純に実行します。ただし、そのような状況では、Github を使用するだけで、気にする必要はありません。
私は自分のマシンで個人用ソース管理システムとして Subversion を実行しており、そのインスタンスで svnserve を使用しています。
ありがとう、いくつかのフォローアップの質問。1) svn サーバーの URL に svn://server/repo としてアクセスすると、ポート 80 も使用されませんか? 2) svnserve に対して LDAP 統合を実行できない場合、ユーザーが認証できる唯一の方法は、ユーザーが svn:// の svnserve.conf の password-db によって参照されるファイルにいる場合、または svn のシェル アカウントを持っている場合です。 +ssh://? 3) https:// によって提供される同じ保護を svn+ssh:// で提供することはできませんか、それとも違いがありますか? (申し訳ありませんが、Enter キーを押すたびに送信される段落をここに配置することはできません。) –</p>
デフォルトではポート 3690 を使用しています。これは実行時に変更できますがsvnserve、svn URL もそれを反映する必要があります。
かなり真実です。svnservepasswd ファイルを使用するほとんどの場所。ただし、バージョン 1.5 以降、SASLを使用できます。しかし、私は誰もそれを使用しているのを見たことがありません。
はい、ssh+svn:// は暗号化されたパケットを提供します。ただし、SSH は実装が難しい場合があります。基本的に、svnserve プロセスを生成して、その特定のユーザーに対して実行する必要があります。つまり、各ユーザーはリポジトリへの直接の読み取り/書き込みアクセスが必要です。ユーザーごとに umask を設定し、全員が所属する Subversion Unix グループを作成する必要があります。次に、これらのユーザーはリポジトリ ファイルに直接アクセスできるため、リポジトリ サーバーにログオンしないようにします。オンライン マニュアルに詳細が記載されています。ただし、最終的には、Unix サーバーと Unix クライアントでのみ機能します。Windows クライアントには SSH がないため、インストールする必要があります。何度か試しましたが、https://の方がずっと簡単です。