なぜWEBサイトをバージョン管理するのか
ファイルに番号を振って見失わないように
HTML・XMLドキュメント、画像にスクリプト、その他諸々…。ホームページ、いやあえてWEBサイトと呼ぼう、を順調に拡張していると、そう遠くないうちに膨大な数のファイルに埋もれることになるでしょう。
そして、ある日戸惑う。「あれ、このファイル…いつのだっけ？」
一見、ファイルのタイムスタンプで判別できそうなものですが、実際はあてにならない場合も多々あるので、結局ファイルの中身を見て判別するのが常となります。その上、そのファイルが文章や画像ではなく、プログラムだったりするとパッと見の判別は困難を極めます。
まあ、これが1回2回の話なら気になりませんが、何度も続くと非常に面倒です。そしてそれは何度も続くものです。
非生産的な作業に時間を取られるのは精神的疲労がどっと溜まりますし、何より頭に来る。
更に大変なのが、複数人で作業している場合。貴様が俺のファイルを上書きしただの何だの、間違いなく紛争勃発に繋がります。
そこで、この愛すべき人間らしいミスを防ぐため、ファイルを更新する度に、機械的にバージョン番号を付けてもらいたいと願うのです。
頻繁に更新される大量のファイルの変化を正確に把握することは、サイト管理に費やす労力の圧倒的削減に繋がるのです。
世代管理は要するにバックアップ
意外と見落としがちなのは、バージョン管理はバックアップも兼ねる、ということ。
考えてみれば当然のことで、各世代のデータが保存されているから、最初のバージョンから最新まで自由に行き来できるわけです。
ですから、以前のファイルを改名してとりあえず残しておく、なんてことをしないで済むのです。古いファイルが必要になれば自由に取り出せるのですから。さようなら、index.html.old。
アップロードではなくアップデート
副産物的なメリットですが、ファイルをせこせこアップロードしなくて済む、ということも魅力的です。
一般的に、制作したコンテンツを公開するには、手元で作ったファイルをFTPクライアント等でサーバにアップロードしていきます。
この当たり前のように行われている作業も、よく考えてみれば面倒なものです。ボタン一発でアップロードが完了するのは実は稀で、普通はアップしたくないファイル（作りかけなど）を除外して、ちまちま手作業で選別しながらアップしてるのでないでしょうか。
そんな手間を軽減するために、/var/www/にチェックアウト（ファイルを取得すること）してしまいます。
こうすることで例えば、手元でファイルを更新してバージョンを上げる。そしたらサーバ側でアップデートコマンド1発。するとサイトが最新バージョンに様変わり。あるいは、問題が発生したので更新する前に戻したい。そしたらまた1発。そういうことなんです。
管理しているファイルが多ければ多いほど効果てき面です。当然アップし忘れなんてありません。
なぜSubversionか
Subversion > CVS
バージョン管理と言えば、長きに渡ってCVSが利用されています。簡単に導入でき安定して動作するCVSは非常にありがたい存在なのですが、ファイル名を変更できないなどの不便が多々あるのも事実です。
そんなCVSの置き換えを前提に開発されたのが、Subversionです。
SubversionはCVSの欠点を補い更に多くの機能が追加されていますが、その中でも一番のポイントは、バージョン管理がファイル単位からリポジトリ単位になったことです。CVSしか知らなかった私は、Subversionを経験し感覚を掴むまでこの良さがわかりませんでした。
リポジトリ単位 > ファイル単位
リポジトリ単位（ここではサイト単位）のバージョン管理は、実際に使用してみると理にかなっていると感じます。
WEBサイトを更新する時、変更するのは1つのファイルだけではなく、ほとんどは複数のファイルから成り立つはずです。
例えば、新規ページを加える場合、a.htmlとb.jpgを追加してindex.htmlの「最新情報」が変更されるとします。2つのファイルが追加されて1つが変更されただけですが、このサイトにとっては、これら3つが揃った時点で初めて「新規にページを加えた」という意味を持ちます。
これが大切なわけです。
この状態をCVSでファイル単位で各々バージョンを振った場合、3つのファイルに関連性はどこにも持たせることはできません（CVSでもタグを使用すれば可能ですがちょっと手間かな？）。
逆に、Subversionでやる場合、3つのファイルが加わった時点のサイトにバージョンを付ける、という方法になるので、本来の目的に添ったバージョンの付け方だと思います。
わっかるかなー。わっかんねーだろーなー。
構想を練る
Windowsとの連携
SubversionでWEBサイトの管理を効率よくこなすために欠かせないのが、Windowsクライアントからリポジトリに直接アクセスできること。
コンテンツはWindows上で制作しますので、そこから直接サーバ上のリポジトリをいじれなければ、ファイルをFTPやSCPなどで一度サーバに転送しなければなりません。それではあまりにも面倒です。
幸いSubversionクライアントが存在しますので難なくいけます。従来のFTPクライアントのようなGUIを持つRapidSVNと、右クリックメニューを拡張するTortoiseSVN。私はTortoiseSVNを使います。
Apache2 or svnserve
私はこれを誤解してたお陰でずっとSubversionを躊躇していました。SubversionはApache2が必須なわけではなく、付属のsvnserveでも動かせます。WebDAVプロトコル経由でのアクセスする必要がなけばApache2は要らないのです。
正直WebDAVには期待していないので、svnserveで行くことにします。尚、svnserveには3種類の起動方法があります。
- inetd経由でアクセス時に「一回限りの」svnserveプロセスを起動
- デーモンとして常時動かす
- ssh経由でプライベートなsvnserveプロセスを起動
気持ちとしてはssh経由でいきたいところですが、何かと面倒そうなのでまずはinetd経由で始めてみます。
これでいきます
これまでの情報を集めるとこんな感じだろうか。Windows上からTortoiseSVNを使って、svnserve経由でリポジトリにアクセス。そして同サーバ内にある/var/www/以下に反映させる、と。
セットアップ開始！
Subversionのインストール
ようやくインストール開始。なんだか、ここに来るまでに随分体力を消耗した気がする…。
inetd経由の起動設定
次にinetd経由でsvnserveが起動するように/etc/inetd.confを編集します。以下の1行を付け足します。
usernameはリポジトリにアクセス権限のあるユーザー名です。rootでの実行は避けましょう。
svn stream tcp nowait username /usr/sbin/tcpd /usr/bin/svnserve -i
TortoiseSVN
Windowsでのインストールなので特に問題ないでしょう。ダウンロードしたインストーラーをダブルクリックするだけです。あと、Japanese Language Packがあるのでこれもインストールしておくべきです。
いざゆかん！
それではいよいよSubversionを使っていきます。
Warning: Sablotron error on line 1: XML parser error 3: no element found in /var/www/amazon/select_item.php on line 43