コミット時に以下のように怒られる。

svn: Can’t get exclusive lock on file ‘REPO/db/write-lock’: No locks available

Google先生に聞いてみるとリポジトリがNFSにあると同じ現象ができているっぽい。

 SubversionのFAQをみるとlockをサポートしているNFSならOKとある。
NFSとかを詳しくは知らないんだけど、Linux.or.jpのNFSクライアントの設定を見てみると、NFSサーバのディスクをマウントする場合、マウントするほうはクライアントとして設定が必要。

Debianの場合、「apt-get install nfs-common」でrpc.statdデーモンとかが動いているらしいが、ファイルロックする場合は、これとセットでrpc.lockdデーモンも必要らしい。そしてこれらはnfslockというのから起動されるらしい。
その他、portmapもいるとかなんとか。

 これで解決しない場合は、リポジトリをローカルディスクにおくっきゃないな。

WebDAV transparent write-through proxyの実験中、Slaveでコミットしたときにwrite-throughしてくれない・・・。なーぜーだー。コミットすると以下のエラーが出る。

コミットに失敗しました (詳しい理由は以下のとおりです): サーバが、リクエストへのレスポンスとして予想外の戻り値 (500 Internal Server Error) を送信してきました (リクエスト: MKACTIVITY, URL: ‘/svn/repo01/!svn/act/fe44baef-2017-234b-bb48-d0f067379dc9′)

SVNMasterURIが間違っているときのエラーらしいけど。
SVNParentPathがまずいかと思ったけど、開発者のブログ？では以下のように解説されていた。

I believe you can use SVNParentPath so long as your repository locations on the master and server end with the same basename, and your SVNMasterURI configuration doesn’t carry that basename. I think the proxy code is going to use SVNParentPath + /basename to find the repository on the slave, and SVNMasterURI + /basename to address the repository on the master. (There’s a mailing list post which corroborates this at: http://svn.haxx.se/users/archive-2008-02/0326.shtml)

SVNParentPathの場合、SVNParentPath ＋ リポジトリ名でやってくれるはずとのこと。
Slave側のログには下のようなのが。

[Sun Dec 14 23:02:17 2008] [warn] proxy: No protocol handler was valid for the [...]

svnsyncはミラーリングの仕組みなのだが、write-through proxyを使うことで、ApacheにくるSVNリクエストを透過的に転送する。
わかりやすくいうと、svnsyncは同期のためのバックエンドの機能で、write-through proxyはSVNへのリクエストを振り分けを行うフロントエンドのもの。2つの技術を合わせて使うと、分散リポジトリ構成を組める。
svnsyncを使ってリポジトリレプリケーションでも書いたが、svnsyncだと、ミラー側のリポジトリはRアクセスしかだめにしないとだめ。そのために、hooks以下のスクリプトでcommitをはじいたりする処理をいれなければならない。
write-through proxyだと、ミラー側に来たリクエストをマスタ側に転送してくれるのでそういった心配が要らなくなる。Proxyぽく透過的にリクエストを転送してくれるのでwrite-through proxy。
この場合、ネットワーク上に1つのマスタリポジトリがあり、コミット処理はここにえいや！と一元的に管理する。それ以外のミラー側（スレーブ）はRを担当することで、たくさんのスレーブを立てて処理を分散することができる。
参考：
・Subversion 1.5 WebDAV Write-Thru Proxies by 本家
・Subversion 1.5.0 での新機能 (WebDAV Write Through Proxy)
・エンタープライズ環境におけるSubversionの複製アーキテクチャ by japan.internet.com デベロッパーさん
・複数のドメインを運営する （バーチャルホスト） by Linuxで自宅サーバさん
・バーチャルホストによる複数サイトの同時運用 by @ITさん

共通して

ドメイン名はいいけど、それ以降のパスはそろえたほうがいい。リポジトリ名もそろえておいたほうが良し。
mod_proxy使うわけだからリポジトリ名が異なると「Unusable URI: it does not refer to this repository」みたいに怒られると思う。
環境は以下。ApacheのVirtualDomainを使って、1台のPCに2ドメインをひっつけて環境を作った。
Subversion1.5.3
Windows Vista。
Apache 2.2
master
・master.daipresents.com:8888/svn
・C:\fujihara\svn_masterがリポジトリ置場
slave
・slave.daipresents.com:8888/svn
・C:\fujihara\svn_slaveがリポジトリ置場

マスタの設定

通常のSVN設定と同じく下のような感じでhttpd.confを設定しておけばよい。

LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule rewrite_module modules/mod_rewrite.so LoadModule authz_svn_module modules/mod_authz_svn.so <VirtualHost *:8888> ServerName master.daipresents.com DocumentRoot "C:/fujihara/Apache Software Foundation/Apache2.2/htdocs" ServerAdmin [email protected] [...]

Subversionリポジトリのバックアップを参考にバックアップについて考察。なんかよくわからないけどSVN構築をまかされた僕には、このページはとても助かっています。感謝です。

考えること

テーマとしては

信頼性をあげて故障する期間を短くしたい 可用性をあげてユーザから見て壊れにくくしたい 保守性をあげて運用しやすくしたい

そのために考慮するのは

バックアップの対象 バックアップ先 バックアップの頻度 バックアップの手段

ちなみにSVNは第15回 オープンソースのバージョン管理ツールに世代交代の波にあるように、

Subversion は，バイナリ差分アルゴリズムを使ってファイルの差分を表現しており，テキストファイルもバイナリ・ファイルも同じ方法で管理される。よって，CVSよりもバイナリ・ファイルの管理が容易におこなえる。

のだ。cvs2svnスクリプトをつかって、CVSリポジトリと変換したSVNのリポジトリを比較したら、CVSよりもSVNのほうが半分以下の容量になった。（たしか5.5MBが1.5MBだった気が）

バックアップの対象

リポジトリルートとなっているフォルダにあるリポジトリすべてが対象になると思う。
コピーを用いない場合、confやhooksディレクトリはバックアップがとれないので注意。必要であれば、こちらもコピーしないとね。

バックアップ先

ここで書いてもなので、ディスクが違っていればどこでもいいんじゃないかな。

バックアップの頻度

リアルタイムに取るか、1日や1週間に1回取るか。

バックアップの手段

SVNでは以下の3つの方法を検討できる。

ファイルコピー svnadmin hotcopy svnadmin dump/load svnsync

ファイルコピー

いいところ
・簡単

悪いところ
・リポジトリがでかくなるとリアルタイムに取ることができない。
・コピー中にコミットするとリポジトリが壊れた

svnadmin hotcopy

試しているところ。

いいところ
・SVN稼働中に安全にコピーできる

悪いところ
・特になさそう

svnadmin dump/load

いいところ
 ・最低限のデータエラー検出をしてくれるが、壊れたリポジトリを直す手段がほとんどないのが微妙
 ・バックアップデータが小さい。1000リビジョンぐらいでサイズは8.33MBのリポジトリが、dumpファイルのサイズは14MB。tar.gzに圧縮すると218KBだった。

わるいところ
・すげー時間がかかる。1万リビジョン1時間ぐらいかかった。loadにも同じぐらい時間がかかるので、障害時復旧に時間がかかってしまう。
・こちらもdump中にコミットしたらリポジトリが壊れた経験がある。
・rootじゃないと実行できない

svnsync

いいところ
・リアルタイムでバックアップ（複製）ができる
・rootでなくても実行できる

わるいことろ
・いまんところないなー

まとめ

リアルタイムの保存であればsvnsync。
複製したリポジトリへの切り替えが簡単なので、SVN1.4以上なら使えそう。

一番良さそうなのはSubversionベストプラクティスにもあるようにhotcopyがよさげ。Googleさんもhotcopy+rsyncらしい。
hot-backup.pyを使えるので導入が楽ちん。

参考： Subversion リポジトリのバックアップ、リストア 【Subversion】ディスククラッシュ subversionのバックアップはhotcopyのがイイ

バックアップとして、もしくはバックアップからの復旧時間が嫌な場合は、リポジトリのミラーリングとしてsvnsyncがSVN1.4から使えるようになっている。

今回はsvnsyncの動作を確認してみる。
環境はWindows Vista、SVN1.5.3。
本当はリモートのリポジトリにミラーリングしたいんだけど、ローカルApacheで我慢。

Apacheは↓みたいな設定でURLを別にしている。SVNのBasic認証もかけてみた。

<Location /svn> DAV svn SVNListParentPath on SVNParentPath C:\fujihara\svn_root AuthType Basic AuthName “Subversion Basic Auth” AuthUserFile C:\fujihara\svn_root\passwd Require valid-user </Location> <Location /svnmirror> DAV svn SVNListParentPath on SVNParentPath C:\fujihara\svn_mirror AuthType Basic AuthName “Subversion Basic Auth” AuthUserFile C:\fujihara\svn_root\passwd Require valid-user </Location>

「http://localhost:8888/svn/repo01」と「http://localhost:8888/svnmirror/repo01m」を同期させる。

ミラー側のリポジトリ設定

まずはミラー先のリポジトリを作成する。

mkdir c:\fujihara\svn_mirror cd c:\fujihara\svn_mirror svnadmin create repo01m

次に「C:\fujihara\svn_mirror\repo01m\hooks」にある「pre-revprop-change.tmpl」を「pre-revprop-change.bat」、「start-commit.tmpl」を「start-commit.bat」にリネーム。Windowsの場合はbatでUnixだとtmpl拡張子を削除かshとかでもいいかも。
バッチファイルの中身を以下に修正。

// pre-revprop-change.bat if “%3″ == “svnsyncuser” exit 0 exit 1 // start-commit.bat if “%2″ == “svnsyncuser” exit 0 exit 1

これをしないと

svnsync: Repository has not been enabled to accept revision propchanges;
ask the administrator to create a pre-revprop-change hook

と怒られる。この記述によって、svnsyncuserからしかアクセスができないようになるので、ミラー側に送られてきたコミットやリビジョンのログメッセージ変更を防ぐ。

次にミラー側のリポジトリを初期化。
ミラー側のリポジトリは空っぽでないと「svnsync: Cannot initialize a repository with [...]

Subversionのセキュリティについて考えてみた。
まず、Subversionのサーバをどうするかで選択肢がわかれる。

svnserve 簡易サーバ。簡単な認証もあるため社内LANならばこれでも問題ない。 svn + ssh SSHで暗号化接続できる。 http Apacheと連携させてhttpで接続する。ブラウザからの確認もでき、Apacheの認証機能をそのまま使える。

まずはsvnserveでのセキュリティを調べてみる。

svnserve

簡易サーバsvnserveの場合は、

svnserve.confによるリポジトリに対するアクセス設定 svnserve.confとpasswdによるリポジトリに対する認証 svnserve.confとauthzによるパスごとのアクセス設定

が可能。svnserveの場合は、どれも再起動せずに設定が反映された。

svnserve.confによるリポジトリに対するアクセス設定

匿名ユーザの場合と、認証済みユーザの場合が設定可能。匿名ユーザは「anon-access」で認証ユーザは「auth-access」となる。値は「none」、「read」、「write」を設定できる。
匿名ユーザのアクセスを制限する場合は、以下のように設定。

[general] anon-access = none svnserve.confとpasswdによるリポジトリに対する認証

認証ユーザの認証はpassword-dbで指定したファイル（ここではpasswd）で設定する。

[general] anon-access = none auth-access = write password-db = passwd

passwdファイルには以下のように設定する。平文なので注意。

[users] fujihara = fujihara dai = dai svnserve.confとauthzによるパスごとのアクセス設定

svnserver.confには以下のように記述する。

[general] anon-access = none auth-access = write password-db = passwd authz-db = authz

authzにパスごとの設定を記述していく。
passwdファイルのメンバーをグループに分ける。

[groups] developers = fujihara,nagasawa manager = fujihara,aragaki

ルートフォルダ直下にはmanagerだけ読み書きができ、それ以外は読み込みだけできるようにする。以下の設定だとnagasawaさんは/all.txtを読むことができても編集できない。

[groups] developers = fujihara,nagasawa manager = fujihara,aragaki [/] @manager = rw * = r

以下の設定だとdeveloperフォルダはmanagerの設定をしていないが、サブフォルダは親フォルダの設定を継承するので、ルートの「@manager=rw」を引き継いでいることになる。よってみんな読み書きできる。

[groups] developers = fujihara,nagasawa manager = fujihara,aragaki [/] @manager = rw * = r [/developer] @developers = rw

以下の設定だと、managerフォルダはmanagerだけがアクセスできる。「* =」だけ書いてしまってもルートの設定を継承してmanagerだけのアクセスになりそうだが、「* =」だけだと全員アクセスできなくなってしまう。

[groups] developers [...]

キーワード展開とは「$作者」みたいにソースに書いたら、チェックインしたときに「ふじはら」みたいに置き換えてくれる機能。CVSにあったのでSVNにもあるだろう。
鍋の底さんのSubversion Book翻訳のキーワード置換を参考に。

キーワード $LastChangedDate$ 省略すると「$Date$」。最後にコミットされた日時。 $LastChangedRevision$ 省略すると「$Revision$」。最後にコミットされたときにリビジョン。 $LastChangedBy$ 短縮は「$Author$」。最後にコミットしたユーザ。 $HeadURL$ そのファイルのリポジトリのパス。 $Id$ 上記キーワードを全部ひっくるめたようなもの。 使い方

SVNではいきなり使えない。ファイルごとに以下の設定が必要。

# $LastChangedDate$ # $Date$ # $LastChangedRevision$ # $Revision$ # $LastChangedBy$ # $Author$ # $HeadURL$ # $Id$ Test

上のようなfujihara.txtを用意して、以下のコマンドを打つ。

repo01>svn propset svn:keywords “Date Revision Author HeadURL Id” ./fujihara.txt property ‘svn:keywords’ set on ‘fujihara.txt’

TortoiseSVNの場合、ファイルを右クリックすれば属性というものがあるので、svn:keywordをキーに「Date Revision Author HeadURL Id」を与えればOK。
これをコミットすると以下のようになる。

# $LastChangedDate: 2008-09-20 21:19:00 +0900 (土, 20 9 2008) $ # $Date: 2008-09-20 21:19:00 +0900 (土, 20 9 2008) $ # $LastChangedRevision: 13 $ # $Revision: 13 $ # $LastChangedBy: $ # $Author: $ # $HeadURL: svn://localhost/repo01/trunk/fujihara.txt $ # $Id: fujihara.txt 13 2008-09-20 12:19:00Z $ Test 自動でキーワード展開してもらう

Unixなら「~/.subversion」が使われる。Vistaの場合、コマンドプロンプトで以下を打つと設定ファイルの場所がわかる。

C:\Users\svntest>echo %APPDATA% C:\Users\svntest\AppData\Roaming

ディレクトリを見てみると、Subversionというフォルダがあり、設定はconfigファイルになるらしい。ここで以下の設定を行う。

[...]