コミットメッセージのフォーマットをプロジェクトごとに定義しておきたい場合は、コミットログのテンプレートを定義しておくと、大変便利です。SVNでは、プロパティ値の設定をすることにより、これが可能となります。
例えば、コミットの際には、修正した内容を概要と詳細に分けて記載するようにコミットログのフォーマットを整える場合、以下のように設定します。
プロジェクト上で右クリックし、[チーム]→[プロパティの設定]を選択し、プルダウンから以下のようにプロパティ値を登録します。
このように設定しておくと、コミット時に設定したテンプレートが表示されるようになり、コミットメッセージのフォーマットを統一できます。テンプレートを利用することにより、コミットメッセージの入力漏れを防ぎ、ソースコードのバージョン管理をきちんと行えるようになります。
Subversionを利用すると、インターネットを利用してユーザーが自由にリポジトリにアクセスできます。しかしながら、逆にセキュリティ面で注意が必要となります。SSLのクライアント認証を利用すると、決められた証明書を持ったユーザーからしかリポジトリへアクセスできなくなり、セキュリティを強化できます。ここでは、簡易なクライアント証明書を利用して、クライアント認証を利用する例を説明します。
まず、Trac月のSSLの設定を有効化します。Trac月で用意されているコマンドプロンプトから、以下のバッチを実行します。
> create-servercert.bat
実行後、証明書の所有者情報を入力します。
入力が終了したら、TracLight\apache2\conf\http.confの下記の行のコメントアウトを外し、Apacheを再起動させてmod_sslを有効化します。
#LoadModule ssl_module modules/mod_ssl.so
次に、クライアント証明書を作成します。TracLight\apache2\conf\sslディレクトリで、以下のコマンドを実行してください。
>openssl genrsa -out client.key 1024 >openssl req -new -x509 -days 730 -batch -key client.key -out client.crt >openssl pkcs12 -export -in client.crt -inkey client.key -certfile client.crt -out client.p12 Enter Export Password: <証明書のパスワード> Verifying password - Enter Export Password: <証明書のパスワード>
Apacheに接続を許可するクライアント証明書の情報を設定します。TracLight\apache2\confディレクトリのssl.confファイルを以下のように修正してください。
#SSLCACertificatePath conf/ssl SSLCACertificateFile conf/ssl/client.crt …… # Client Authentication (Type): # Client certificate verification type and depth. Types are # none, optional, require and optional_no_ca. Depth is a # number which specifies how deeply to verify the certificate # issuer chain before deciding the certificate is not valid. SSLVerifyClient require
クライアント認証が有効化されたサーバにアクセスするために、Subversiveからクライアント証明書を設定します。
SVNリポジトリ・ビュー上でクライアント認証を行いたいリポジトリのロケーション・プロパティを選択します。「SSL Settings」タブを選択し、[Enable Client Authentication]のチェックボックスにチェックを入れて、作成したクライアント証明書のインポートを行います。証明書作成時に設定したパスワードを入力し[終了]ボタンを押します。証明書をインポートする際、[CertificateProblem]という警告が出ますが、証明書が信頼できるものであれば、[Trust]を押してインポートを終了してください。
SVNは、CVSの使い勝手を継承しながらCVSの使い勝手が悪かった部分を改善し、より完成度の高いバージョン管理システムになっています。Eclipseから利用した場合、CVSと同様のインターフェイスを提供し、CVSユーザーの移行が簡単になっていることも特徴的です。
SubversiveのEclipse FoundationへのProposalが承認され、Eclipse Foundationで開発が行われるようになったことも踏まえて考えると、SVNがバージョン管理システムのデファクトスタンダードを担っていく日もそう遠くはないでしょう。
現在運用中のCVSをSVNへ移行するのは、なかなか難しいもしれませんが、新しいプロジェクトでバージョン管理システムの導入を検討されている方はSubversionを検討してみてください。
Copyright © ITmedia, Inc. All Rights Reserved.