読了：「業務システムのための上流工程入門」

「業務システムのための上流工程入門－要件定義から分析・設計まで」（著：渡辺幸三）

　この書籍のコラムを読んで「はっ」と思ったけれど、確かに情報システムの業界には、設計業を専門に請け負う者が居ない。居るのは下流工程までを含めて行うシステムエンジニアまたはプログラマか、もしくは超上流である企画のみを行うコンサルタントという人だけだ。本当はシステム設計（システムアーキテクト）という職種があってしかるべきなのかもしれない。ここでいう設計とは「外部設計」とか「基本設計」と呼ばれる領域のことを指す。情報システムを構築する際、この領域こそがもっとも重要であることは誰もが認識している。けれど、それを専門的に行う人が、この業界にはほとんど居ない。

　情報処理技術者試験における旧アプリケーションエンジニア試験、今年度からのシステムアーキテクト試験とは、まさにこの上流工程の設計者をターゲットにしている。本当ならば、ＰＭと同じくらいに重要で、人手不足な領域である。

　著者の方は、数少ない設計のスペシャリストなのだと感じた。こういう人をちゃんと評価する仕組みが、この業界にはまだまだ無い気がする。たいてい、設計の腕が良い人は、何故かプロジェクトマネジメントに注力する方向となり、やがて職種はプロジェクトマネージャーになってしまう。業務システムのアーキテクトは必要だと言うのに…。

　僕の場合、属している企業グループの特性から、ひとたび開発となると規模が尋常な数字ではなくなる。それがプロジェクトの巨大化に繋がり、上流工程への参加機会は、数としては多くなくなっている。また、巨大プロジェクトが多いということは、それだけでプロジェクトコントロールの困難性が増すため、とにかく求められるのはＰＭ力だったりする。しかし、ＰＭ力だけでは何も生み出せない。やはりアーキテクトが居ないといけないんだろう。

　この本はそういうことをいろいろ考えさせられる。無駄なところがなく、実践的なスキルにつながる良書である。これは人に勧めても良い書籍だ。個人的にはユーザ企業の情報システム担当の人に読んで欲しいな。上流工程は、実は彼らの働きにかかっているのだから。…まあ僕もユーザ系システム子会社ＳＥなので、立場はあまり変わらない。僕ももっとこういう本を読んで勉強すべきだと思った。
　改めて上級ＳＥに求められるスキルとは何かがわかった。データベース概念設計やユーザインタフェース概念設計くらいを即興でできるくらいではないといけないんだな…。まだまだ勉強が足りないようだ。

　一日で読了する予定が三日もかかってしまったけれど。図書館へ行く機会をこうやって増やさないといけないな。

ＩＴニュース：この買収劇はけっこうショッキングだと思う。

　昼休みに自席でネットニュース見ていたら、「オラクルがサンマイクロシステムズを買収する」だって。これはけっこう業界的には大ニュースではないかな。Ｊａｖａのオープンな環境は守られのかな。一応メモとして記す。

　…某芸能人の逮捕より僕的にはこっちの方がニュースだな。まあ僕は彼を俳優としては買っていたんだけれどな…。

バックアップとか…。

　就業制限を理由に、一昨日、昨日と普通にお休みをいただいていたわけだけれど、明けた月曜日は、朝からバタバタしていた。もっとも僕は話には加わるけれど、基本的には戦力外。特に今月あと２日間は。

　業務運用開始ではないので幸いだと昨日書いたけれど、それでも開発プロジェクトとしては客先にシステムを提供しているわけだから、問題がある場合には基本的には即応体制としなければならない。まあ二桁億の開発プロジェクトだからね。リリース直後なんて、こんなものでしょう…などと言ったら今は強く叱責されてしまう世の中。厳しいね。

　僕はとりあえずできることをやるか。その一つがプロジェクトでこれまで協力会社から納品されたもの、もしくは我々が親会社に納品したもの。それらの整理。そして、使っていた共用フォルダ領域のバックアップ。

　バックアップなんて恒常化されて当たり前だと思うだろう。でも、そんな当たり前が当たり前に実施されているプロジェクトが本当にほとんどだろうか？

　少なくとも、僕が今扱っているプロジェクトは、すでにあるＮＡＳサーバには入りきらないほど膨大になってしまったので、自動的にはバックアップができていない。何ということだろう。だから僕が時々スナップショットを裏で取っている。

　Windows標準でバッチ処理に使えるコマンドはXCOPYだけだと思っていた。でもXCOPYってフォルダの階層が深くなりすぎると…具体的にはフルパスで256文字を超えると、そのファイルをコピーしてくれないどころか、そのときのエラー処理もしてくれない。

　でも、Robocopyというコマンドがあったのだ。「Windows Server2003 Resource Kit Tools」としてマイクロソフトのサイトからダウンロードできる。こっちの方がバッチ処理でバックアップに使う場合、いろいろ優れているようだ。特に長すぎるフルパスにも対応してくれる。

　Windows環境におけるフルパスの最大長は、けっこう謎に包まれているのだけれど、このリソースキットに添付されている解説を読むと「およそ32000文字」とある。本当かよ？

　まだ、使い勝手を自分のものにしていないので、解説はできないけれど、大規模な共用フォルダのバックアップには、こっちの方が良いかもしれない。

　…。

　というわけで、とりあえず今日の深夜に実行されるように仕込んでおいた。明日結果を見てみよう。

[IT覚書][subversion]業務で大量のファイルを扱うときはやっぱりコマンドラインだね。

　どうしてもＧＵＩの方がとっつき易い。それはそうだろう。僕もたとえばＳＶＮ(subversion)を業務で使い始めたときは、クライアント側では TortoiseSVN を使っていろいろと感触をつかんだ。TortoiseSVN は Subversion 本家との互換性がとても高く、Subversion のクライアント側の機能のほぼすべてを GUI で実行できる。
　もともと Subversion 自身が、サーバ機能とクライアント機能の両方を兼ね備えていることもあり、TortoiseSVN だけでも、ローカル環境に限定するなら、リポジトリの構築もできる。これはつまり、バックアップソフトとして Subversion を個人環境で使いたいといった場合には、TortoiseSVN だけですべて足りるということである。

　…。

　一方で、僕は業務システム開発の現場で、Subversion を使っている。ドキュメントサーバ(Windows Server 2003 R2 サーバ)に、Subversion 1.4.5 を導入している。そしてネットワーク上の共用フォルダに「作業コピー」を配置することで、複数のライブラリアンによるチェックができるようにしている。まだまだ運用は常に継続的改善中だけれど。

　「バージョン管理システムを導入しさえすればライブラリアンが必要なくなる」といった意見をよく耳にするけれど、それは絵空事だと思う。バージョン管理システムはあくまでも道具に過ぎず、ライブラリアンの仕事の効率化に一役買ってくれることは事実だけれど、そんなに言われるほど作業量を激減できるわけでもない。ライブラリアンはバージョン管理システムの仕様を踏まえ、相性の良い運用を行わなければならない。そう。バージョン管理システムの仕様をしっかりと押さえた上で運用しないとかえって作業量が増えることもある。

　…。

　現時点での最新バージョンは、1.5.4 あたりのはずだけれど、このバージョンでも「タイムスタンプの保持」の問題は解決されていない。バージョン管理とは一種の文化だから、仕方がないのかもしれない。ＳＶＮを開発している人たちの頭の中には「タイムスタンプを固定してしまうと、それはけっこう前の日時情報を持つことになるので、タイムスタンプの更新をビルドのトリガーにしているようなプロジェクトでは、とても危険な行為じゃないか」…という考えがあるんだろう。

　しかし、僕の所属している（もしくはしてきた）プロジェクトの文化では、内容的に何にも変わっていないファイルのタイムスタンプが、チェックアウトされただけで変更されてしまうことに、逆にものすごい違和感を感じるんだ。つまり、バージョン管理システムにはいっさいファイルが持っているタイムスタンプをいじってほしくないのだ。タイムスタンプを変更するのは「そのファイルを実際に開いて保存した人」だけにしたいのだ。

　今後、現行システムの保守をやっているチームにもＳＶＮを知ってもらい、使ってもらう必要があるけれど、このタイムスタンプ問題は、必ず問題視されるだろう…。

　…。

　現時点で、その問題を少しでも軽減しようと思うなら、「ファイルの日付を"最後にコミットした日付"に設定する」というオプションを使うことくらいしかない。Subversion,TortoiseSVN ともに初期設定ではオフになっているオプションだ。

　TortoiseSVN では「設定」画面でそのオプションのオン／オフを設定できる。それでは、コマンドライン版の Subversion ではどうするのか。けっこう悩んだけれど、クライアント側の設定ファイルを書き換えることで同じことができるのがわかった。

　WindowsXP であれば、下記の位置に設定ファイルが作られている。（隠しフォルダなのでエクスプローラの表示設定を変える必要がある）

　C:\Documents and Settings\
　　[USERNAME]\Application Data\
　　Subversion

　ここに、config という拡張子もないテキストファイルがある。この内容を編集する。

# use-commit-times = yes

　という行がある。これは先頭に「#」がついてコメント行扱いになっている。これを有効化する。

use-commit-times = yes

　ここでの注意点は、行頭にスペースを入れないことである。

　…。

　ついでに、同ファイル内に、editor-cmd 行も有効化／修正しておけば、コマンドライン版 Subversion からリポジトリにメッセージログをスクリーンエディタで編集することができる。

editor-cmd = %SystemRoot%\system32\notepad.exe

　こうすれば「メモ帳」が登録される。
　注意点は、同じく行頭にスペースを入れないことである。

　…。

　使い方にもよるけれど、たいていの小規模なコミット（チェックイン）ならば、TortoiseSVN のＧＵＩでやった方が良いだろう。でも、大規模な開発プロジェクトにおいて、ものすごく大量のファイルをコミットする場合、作業の証跡を残すと言う意味でも、コマンドライン版を使用して、確実にログを取ることが望ましい。

　ここで誤解しないでほしいことは、コマンドライン版 Subversion に特殊なロギング機能があるわけではないということ。もしそんな機能があったならば、ＧＵＩ版の TortoiseSVN にも実装されていたはずだ。

　コマンドラインでは、普通に標準出力（またはエラー出力）をリダイレクトできるというだけである。

　変更をチェック(svn status)の場合なら

svn stat [パス名] >> [ログファイル] 2>&1

　…という感じで。

　…。

　それにしても、最近の人たちはコマンドライン操作に、本当に慣れていない。これも Windows がもたらしたものだろう。
　Unix/Linux 環境のファイルを操作するのに、FFFTP (ftpクライアントのＧＵＩソフト：優れたフリーソフトだ) で、それをあたかもファイルエクスプローラみたいな使い方をしているんだもの。
　その使い方はどうなんだ？

　まあ、これはおじさんの愚痴だな。

[IT覚書][Windows]コマンドラインからフォルダを全消去する方法。

　つまり、UNIXでいうところの「rm -rf」をDOSコマンドでやる方法。（厳密にはもうDOSなどという言葉は死語ですね。Windowsのコマンドプロンプトという方が正しい）

　昔はディレクトリと言っていたものをフォルダと言うようになったのはWindows95からかな。昔のMS-DOSではディレクトリと呼んでいた。僕は頭の中でいつもフォルダ→ディレクトリと変換している。（いまでもUNIX/Linuxでは普通にディレクトリと言うけれど）

　まあ、そんなことはさておき。パッとやろうとして「どうやるんだったっけ？」となったのが、フォルダ全消去。Windows Server 2003 R2 上で動くバッチファイルの中で書きたい。

　DOSにも rmdir コマンドはあった。さらには一時期 deltree などという怪しげなコマンドもあったようだ。（これは使ったことはない）
　rmdir /? でヘルプを出して確認。普通に rmdir /s /q で行けそうか？　試してみると「ファイルが存在する」という理由でエラーを返される。

　これは昔からのDOSの仕様なのか、ファイルとディレクトリとは別に考えるようになっている。大まかに言うと、del は主にファイルを消去するコマンドであり、rmdir はディレクトリだけを消去するコマンドである。

　以下のような順序で実行すると、複数のファイルを含んだ多重構造のディレクトリを消すことができた。

  del /s /f /q [dir]
  rmdir  /s /q [dir]

　ただし、厳密に言うと UNIX系の rm -rf （ディレクトリを再帰的に消去し、確認メッセージも出さないで強制的に実行する）とは、ちょっと違うことが起こる。
　del コマンドにおいて消去されたファイル名が標準出力ストリームに出てくる。
　まあ、僕は情報が何も出ないよりは出てくれた方がうれしいので、上記のやり方で問題ないと思っている。画面に標準出力を向けたままでは、ただ画面が流れるだけなので、もちろん以下のようにするのが普通である。

  del /s /f /q [dir] >> [logfile] 2>&1
  rmdir  /s /q [dir] >> [logfile] 2>&1

　こうすると任意名のログファイルに標準出力とエラー出力の両方が出力され、画面には出力されない。こういったリダイレクションは、もともとUNIXからDOSに引き継がれた仕様なので、同じようにできる。だが、UNIXでできるリダイレクションがすべてできるわけではない。Windowsのコマンドプロンプト用のシェル「CMD.exe」は、UNIXの各種シェルに比べると貧弱である。

現場の実態。

　現プロジェクトは従来からのウォーターフォール開発プロセスだ。大規模は未だにこれが現実だ。
　一方で、当社の開発基盤は、「バージョン管理」を日常的に行いながら「継続的インテグレーション」（CI）を行うことを推奨している。バージョン管理は subversion を使い、CI は CruiseControl を使う。両方共にOSS（オープンソースソフトウェア→無償）だ。CI とは、プログラムの単体テストとビルドを自動化して毎日のように実行するやりかただ。（定期ビルドと定期テスト）
　これはウォーターフォールのような直列的な開発プロセスには適用しづらい。こういうのはテスト駆動型のプロセスで最大の効果を生む。（少なくとも僕はそう理解している。もしかすると違うのかもしれない）
　またまた一方で、当社の「PM標準」というものでは、開発プロセスは従来型（ウォーターフォール）を標準としている。

　僕はいまのプロジェクトの状況を様々な視点から勘案しても、バージョン管理は保守を見据えても実践すべきだけれど、定期ビルドなどといった CI は、導入できないと考えた。
　そもそも今月中に、バージョン管理に使うリポジトリの整備と、手動によるビルド環境を、なんとか構築すべく、若手への働きかけをしながらギリギリでやっている。この状況下で僕にとっては未知な「継続的インテグレーション」はとても導入できない。
　…というか、既に工程が結合テストに入っている局面では遅い。また、僕の中に CI を導入した場合の良いイメージがないことも理由だ。わからん者がわからんモノを導入してはうまくいかない。

　ああでも、開発基盤の人たちからは、だらしなく思われるのだろう。現場の言い分もあるにはあるが、あまり言っても平行線だろうし。

　僕があと1.5倍くらい働けたら、状況は異なっていたかもしれないけれど、それもタラレバに過ぎない。

　来週のリーダー会議でははっきりと言おう。CI はやらない判断をしたと。

　未来にあるであろう新規開発では、もっと初期の段階から構成管理環境を整えよう。

[IT覚書][Linux][subversion]rpm形式の最新ではないバージョンを取得する。

　日記に書いているように、職場でのドキュメントサーバ（Windows Server 2003 R2）におけるバージョン移行（1.3 系→ 1.4 系）は先週実施できた。後はビルドサーバ（Linux:RHEL）における svn クライアントの移行や導入が残っている。Red Hat だから rpm でインストールする。そのやり方を事前に整理してみた。

1.インストールしたい subversion の
　パッケージを取得する

1-1.svn本家URL <http://subversion.tigris.org/>

1-2.「Get Subversion」という部分から「Red Hat binaries」<http://subversion.tigris.org/getting.html#redhat>を選択→リンクへ移動

1-3.「SummerSoft」<http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/>を選択→リンクへ移動

1-4.svnのバージョン1.4系が欲しいなら、「rhel-4/」を選択→リンクへ移動

1-5.インストール対象マシンのCPUアーキテクチャがインテル386であれば「i386」を選択→リンクへ移動

1-6.例えば 1.4.5 が欲しいのであれば、「subversion-1.4.5-1.i386.rpm」が対象のパッケージとなる→それをダウンロードする
（1.3系はディレクトリは存在するけれど、1.3系そのもののrpmは無いみたいだ…）

1-7.パッケージの検証

　作業用ディレクトリにrpmファイルを配置して

$ md5sum ./subversion-1.4.5-1.i386.rpm
$ rpm --checksig ./subversion-1.4.5-1.i386.rpm
$ rpm -K ./subversion-1.4.5-1.i386.rpm  などなど

2.インストールされているパッケージを削除する

2-1.作業ディレクトリに移動

2-2.インストール状況を確認

$ rpm -q subversion
$ rpm -qi subversion
$ rpm -qa | grep subversion
$ rpm -qa | grep svn
$ rpm -qR subversion
$ rpm -ql subversion
$ rpm -qf /usr/sbin/svnseve
$ rpm -qRp subversion-1.3.1-1.i386.rpm  などなど

2-3.アンインストールを実行

$ rpm -e subversion

(-e:--erase)

-v が効くなら -ev

3.新バージョンをインストールする

3-1.これからインストールされるファイルを調べる

$ rpm qlp ./subversion-1.4.5-1.i386.rpm

3-2.新規インストールの実行

(testing)
$ rpm -ivht ./subversion-1.4.5-1.i386.rpm
(go)
$ rpm -ivh ./subversion-1.4.5-1.i386.rpm

echo などで実行ログをとることを忘れずに…。

（echo 時に -h:--hash オプションがどうなるのかちょっと不明）

3-3.アップデートインストール（参考）

　今回はこれを使う予定はないけれど参考までに。

$ rpm -Uvh ./subversion-1.4.5-1.i386.rpm

$ rpm -Fvh ./subversion-1.4.5-1.i386.rpm

　通常にアップグレードという意味では -U みたい。-F との違いはちゃんと調べた方が良さそう。

いまは家では試せないので、とりあえずのメモ。

今日の日記：まあマイペースですよ。

　今日、午前は昨日の説明会の議事まとめ。僕は昔から議事録は過剰なくらいに書く。「議事録」は近年では「議事メモ」と呼ばれるようになって内容も簡素なものとなっている。内容が薄くても書かないよりはマシだという考え方が主流になりつつある。

　午後はLinuxサーバへの subversion インストール手順を調べた。開発基盤の人とも話した。Linuxでも業務サーバでは圧倒的なシェアを誇るのがRHEL(Red Hat Enterprise Linux)である（あくまでもLinuxではだけれど。数的にはWindowsServerの方が多い）。Red Hat だからrpm形式のパッケージなんだろうと思っていたら、やっぱりそうだった。パッケージ管理システムがちゃんと動いてくれればすんなり行くだろうけれど、ハマると怖そう。

　先日ちょっと愚痴を言った情報処理技術者試験の件。今日インターネット申し込みをした。10年以上受けていない高度試験は何を受けようか迷ったけれど、PM（プロマネ）にした。はっきり言って一発では受かりそうに無い。それでもテクニカルエンジニアネットワークよりは、僕にとっては与しやすいと思える。将来的にはネットワークやデータベースが欲しいところ。

　まあマイペースですよ。

昨日と今日の日記：この時期HDDクラッシュに注意せねばいけなかったのに。

　先週の金曜日に、ドキュメントサーバ(WIndowsServer)のバックアップスクリプトを流したまま帰宅した。それに伴ってローカルPCも起動したままだった。この蒸し暑い中、それはPCのハードディスクには災いしたようだった。
　月曜日に自席のPCを見てみると、画面は真っ暗でHDDからは異音がする。一発で「あーHDDがヤバいかも」と思った。湿度と温度が高い状況はHDDにとても良くないのだった。
　案の定、いろいろ手を尽くしたものの起動はできなかった。水曜日（明日）に開催予定のsubversionの説明会
にも使おうと思っていたのに。それでなくとも長年使ってきたいろいろな環境が入っていたのに。かなりショックだ。

　一方で、昨日と今日とで、ドキュメントサーバの subversion のバージョンアップ作業も決行した。他プロジェクトで既に保守運用に入っているリポジトリもあったので、慎重に行う必要があった。けっこう難航した。サーバサービスの起動という、ソフトの種類にあまり依存しなさそうな部分でハマった。
　まだLinuxサーバの方が残っている。どうやるんだ？　LinuxでRed Hat系ならrpmパッケージだと思うので、パッケージ管理システムでインストールするんじゃないかと思っていたけれど、違うらしい。
　まあこれは後日改めてとなった。

　やっぱり実際に手を動かさないとわからないものだと改めて思った。

　なんだかんだと、見かけよりも余裕がない。あいかわらずギリギリの日々だ。

[IT覚書][subversion]最新版管理だって難しい。

　つい昨日、TortoiseSVN の 1.5.2 がリリースされたようだ。対象 svn サーバのバージョンは Subversion 1.5.1 である。
　1.5.x 系が安定するのはもう少し先かもしれない。

　バージョン管理システムというのは一種の文化であり、本来ならば何気なく運用されるべきなんだろう。そしてそのためには、プロジェクトに参加している人すべてが、バージョン管理システムの仕様を理解していないといけない。一部の人だけが知っていても意味が無い。

　ちょうど一年前携わっていた、大規模システム開発の基本設計において、僕は構成管理の役目を担ったので、まずネットワークで共用しているドキュメントサーバにおけるディレクトリ／ファイルの命名規則などを作った。
　最も口を酸っぱくして言い続けたことが「ドキュメントの最新版が入っているディレクトリには最新版だけ入れて古いファイルは消してしまうか別ディレクトリに移動させろ」ということだった。

\010_最新成果物
\020_成果物履歴

　などというディレクトリ名を決め、ここでいう「\010_最新成果物」の中には、文字通り最新の成果物しか入れてはいけない。同じディレクトリに日付で区別された複数の版が存在していてはいけない。
　このことを割と初めの段階から言い続けていたので、大人数で一斉にドキュメントを作成したときにも大きな混乱はなかった。これはバージョン管理よりももっと基礎となる「最新版管理」だ。なんだそんな基本的なことか。そう言われるかもしれない。でも、これは皆がちゃんとやろうとしないとすぐに崩れる。

　バージョン管理システムをちゃんと使えば、このようなことをしなくても良くなる……はずである。あくまでも、バージョン管理システムがどういうものかを皆が理解して運用することが前提となる。

　来週、グループ内部向けに、3回めとなるsvnの説明会をやる予定。啓蒙活動である。

　…開発言語に関する話題はまたいずれ…。

今日の日記：COBOLは死なず。

　先週の会議で聞いた話だけれど、来年度から新入社員研修にCOBOLを復活させる動きがある。知らない人のためにごくごく簡単に説明するならば、COBOLとはプログラミング言語の一種で、40年以上の歴史がある。FORTRANなどと並んで、今現在でも業務で使用されているプログラミング言語としては最古のものの一つだ。第三世代高級言語とも呼ばれている。主としてホストコンピュータで稼働するシステムの記述に使われ、コンシューマ向けのパソコンではほとんど使われていない（これはCOBOLベンダーの怠慢のせいだと思う）こともあり、一般にはあまり知られていない。（ホストコンピュータとは、メインフレームや商用UNIXサーバである）
　いまでは情報処理の学校でもあまり教えられなくなった。新入社員研修でもJava言語が主流だ（C言語すら教えていないのには参った）。それなのにCOBOL復活。何ということはない。COBOLを知らないとシステムの保守ができないという現場の声が、やっと反映されただけだ。

　昨年および今年は、新入社員研修でCOBOLを教えてくれないので、現場で演習形式で研修が行われている。その前の年は外部の研修を受けさせた。でも外部だと実際の現場環境とは異なるプラットフォームでしか演習ができない。言語を学習するには、実は実行環境を知らないとダメなのだ。

　２年目の若手によっていつの間にかうちの部のWikiにCOBOL学習用のwikiが構築されたので、さっそく書き込んでみた。メインフレームでいうところの順編成ファイル(SAM)は、厳密に言うならサーバやPCにおけるプレーンテキストファイルとは同じとは言えないことなど。

　いまのところ無反応。ヒマなオヤジだと思われたかもしれない。
　昔はこんな文章を書いていた（いま読むと直したいところがいっぱい）ので誤解されるかもしれないが、僕はコボラーなどと呼ばれる人ではない。（と自分では思っている）

　肝心の自分の仕事の進みは今ひとつ。開発支援チーム定例などもあったけれど、なんだか時間が経つのが早い。いかん。明日はちゃんと仕事しよう。

[IT覚書][subversion]異なるバージョンで作業コピーを作る。

　本来ならば今月の初旬にはやっておきたかったことを、ようやく今日やれた。クライアントPCではなく、WindowsServerを使っての、Subversion 動作確認。どういう挙動をするかという情報は、案外表に出ていない。基本的には自分で試すしかないのだろう。

　うちのグループの構成管理サーバである WindowsServer2003 R2 には、Subversion ver.1.3.1 がインストールされている。これは近々に ver.1.4.5 にバージョンUPする予定だけれど、他のプロジェクトも使用しているので勝手にはできない。
　それでも基本的な仕様は変わらないので、いまの状況で色々と試している。やっとサーバの admin 権限ももらえたし。

　発見があった。svn 1.3 で作成したテスト用リポジトリから、まったく同一のタイミングで、同じ範囲を、二つの「作業コピー」にチェックアウトしてみた。一方はサーバのコマンドラインで、もう一方はGUIクライアントである TortoiseSVN 1.4.5 で。その二つのディレクトリのファイルリストをとって比較してみると、内容が違う。「.svn」ディレクトリの内容が違う。
　1.4.5 によって作られた作業コピーの「.svn」方が軽量化されているみたい。でも、違うということは、互換性の問題があるわけで…。おそらく、TortoiseSVN の方で作られた「作業コピー」を、svn サーバのコマンドラインからは扱えないだろう。もしくは扱うと内容がこわれる。
　「作業コピー」を共用ディレクトリに作る場合はかなりバージョンの注意はしないといけないだろう。

[Linux][IT覚書][subversion]バージョン管理を始めてみる。

subversion 関連　備忘録です。
自分のホームのテキストと、Webページのソースをとりあえずリポジトリに入れてバージョン管理を開始します。

★その１．Subversion リポジトリを作る

リポジトリ自体は、/var/lib/svn/repo
初期インポート元、~/temp
作業コピーは、~/work

　root になってみる。

$ su
パスワード:
su: 認証失敗

　ああ、ubuntu ではこうやるんだった。

$ sudo su
[sudo] password for kazuya:

# pwd
/var/lib
# mkdir svn

# ls -al ./svn
合計 8
drwxr-xr-x  2 root root 4096 2008-06-28 15:32 .
drwxr-xr-x 50 root root 4096 2008-06-28 15:32 ..

# cd ./svn/
# pwd
/var/lib/svn

　ここにリポジトリ作成。

# svnadmin create repo
# ls -al
合計 12
drwxr-xr-x  3 root root 4096 2008-06-28 15:34 .
drwxr-xr-x 50 root root 4096 2008-06-28 15:32 ..
drwxr-xr-x  7 root root 4096 2008-06-28 15:34 repo
# ls ./repo/
README.txt  conf  dav  db  format  hooks  locks
#

★その２．リポジトリ内に trunk ディレクトリを切って
　　　　　初期インポートする

　メッセージ"trunk create 20080628"とともに
　trunk を作成する。

$ svn mkdir file:///var/lib/svn/repo/trunk \
  -m "trunk create 20080628"

リビジョン 1 をコミットしました。
$ ls -l
合計 8
drwx------ 4 kazuya kazuya 4096 2008-05-04 13:17 local_html_master
drwxr-xr-x 2 kazuya kazuya 4096 2008-06-28 15:46 text

　メッセージ"first import 20080628"とともに
　trunk下にインポートする。

$ svn import -m "first import 20080628" ./* \
  file:///var/lib/svn/repo/trunk
svn: import コマンドへの引数が多すぎます

　あれ？　怒られた。じゃあこうかな？

$ svn import -m "first import 20080628" . \
  file:///var/lib/svn/repo/trunk

（リストが標準出力に出る）

追加しています  (バイナリ)  ...
追加しています              ...
追加しています  (バイナリ)  ...
追加しています              ...
追加しています              ...
...

リビジョン 2 をコミットしました。
$

★その３．リポジトリの中身を見てみる

　どのコマンドを使うと良いのかな？

$ svnlook tree
リポジトリの引数が必要です
使用方法を知りたいときは 'svnlook help' と打ってください。
$ svnlook tree file:///var/lib/svn/repo/
'file:///var/lib/svn/repo' は URL です。そこはパスで指定するべきです
$ svnlook tree file:///var/lib/svn/repo/trunk
'file:///var/lib/svn/repo/trunk' は URL です。そこはパスで指定するべきです

　…。
　なんかコマンドが違うみたい。
　こっちかな？

$ svn list file:///var/lib/svn/repo/trunk/

　これだと trunk １行しか出てこない。

$ svn list -R  file:///var/lib/svn/repo/

（リストが出る）

★その４．チェックアウトして
　　　　　バージョン管理を開始する

$ pwd
/home/kazuya
$ ls
Examples           svn01.log  テンプレート  ドキュメント  音楽  公開
old_bookmark.html  temp       デスクトップ  ビデオ        画像

　インポート元はもう要らないのでバッサリ削除する。

$ rm -rf ./temp
$ ls
Examples           svn01.log     デスクトップ  ビデオ  画像
old_bookmark.html  テンプレート  ドキュメント  音楽    公開

　作業コピー用ディレクトリを作成する。

$ mkdir work
$ cd work/

　ここにチェックアウトする。

$ svn checkout file:///var/lib/svn/repo/trunk ./

（以下のようなリストが出る）
A    local_html_master/homepage2/ayuzaka/ail.htm
A    local_html_master/homepage2/ayuzaka/xxx.htm
A    local_html_master/homepage2/ayuzaka/yyy.htm
A    local_html_master/homepage2/ayuzaka/hi_ranking_cinema.htm
A    local_html_master/homepage2/ayuzaka/backup.bak
...
リビジョン 2 をチェックアウトしました。
$

$ pwd
/home/kazuya/work
$ ls
local_html_master  text
$

　ディレクトリの指定に一定のクセというか、決まりがあるみたいでした。
　trunk を指定すると、trunk 自身ではなく、その下の階層から出てくる。

　やっぱりGUIじゃなくてコマンドで試すべきだ。
　基本的な動きやクセがわかる。

以上、備忘録でした。

今日の日記：なぜかxcopyコマンドの実験をした。

　先週は会社でも悩んでいたんだ。
　バージョン管理に Subversion (TortoiseSVN) を使うに際して、異なるリポジトリから切り取られた複数の「作業コピー」の内容をどうやって整合を保たせるか。
　考えた挙句、昔なつかしの MS-DOS コマンドの世界の XCOPY を使ったバッチファイルを作るという、地味な結論にたどり着いた。

　今の世代の XCOPY コマンドは、多少は頭がよくなってはいるけれど、かなりクセが強いコマンドになっている。そのため、
「MS-Windows xcopy コマンドの使い方」
…などというメモをまとめたりした。

　ああ！　本当は他にもいろいろとやったり考えたりしたかったのに、これしかできていないー！

　先ほど、本棚に「MS-DOSバッチファイル パソコン使いこなしテクニック」などという１８年も前の書籍を発見した。会社に持って行こう。１８年前。よくこんな本を大事に持っていたよなぁ。

　もう４月も事実上の最終週だ。飲み会とか人事面談とかあるけれど、なんとか乗り切ろう。

昨日と今日の日記：日々勉強。

　昨日の、特に午前中はかなり調子が悪かった。その前の晩に何度か中途覚醒があり、その影響か、もしくは前日までの疲れか、睡魔に襲われたりして、なかなか集中できなかった。ここまでなのは最近では珍しいことだった。
　それでも午後には何とか持ち直した。重要な打ち合わせも無かったので、幸いだった。

　仕事の効率という観点では、昨日は最悪だった。しかし、勉強にはなった。今回の開発プロジェクトは前から言っているように、単純できれいな新規開発ではない。だから複雑な事情が絡み合っているのだけれど、それでも新しいアーキテクチャーを採用する部分はすべてWebベースであり、開発／稼動環境もJ2EEサーバ＋Java系フレームワークを使用する。実際の開発作業にあたっては、これも近年ではデファクトスタンダード（のひとつ）になりつつあるEclipseと呼ばれるオープンソースな環境を使う。

　最新のEclipseを試しに入れてみるかと思ったら、かなりはまった。プラグインという名のディレクトリはまだわかるけれど、フィーチャーって何だよ？　中を見てみるとjarファイル（Java中間コードのアーカイブ）だらけだったりする。なぜ素直にライブラリと言わない？
　この世界って、とにかく言葉の齟齬が頻発するのが難である。やっていることや工夫の考え方は、実を言うとそんなに進化していない。つまり誰でも考えることは同じだということだ。でも、同じようなことなのに、まったく違うような言葉で表現される。ことばを作りたがる人が居るのだろう。

　結果としてはいずれ、今回採用する某Ｈ社のJ2EEサーバ向けにカスタムされたEclipseベースの製品（今風に言うならEclipseディトリビューション）を使うことになりそうなので、やり直しだけれど。

　まあこんなことをやって居ても誰も文句を言わないのだから、それだけ恵まれているのだろう。

　今日は打ち合わせというか、いろいろと細かい雑事と、グループ会議とか業務改善活動とか顧客（親会社）からのプレゼンがあったり。

　当プロジェクトで募った技術書を大量に購入し、それが届いた。自分が読みたい分はちゃっかり手元に置きながらも、若手のメンバーに渡す。ドッグイヤーはいけませんよ、と図書委員みたいなことを言って。

　当面は構成管理担当として、Subversionをどう適合させるか。開発環境とどう連携させるかを、早いところ決めないといけない。
　明日はそのあたりの協議をする予定。（先日はキーパーソンが来てくれなかったので、あまり話が進まなかった）

　それにしても、オープンソースな開発環境のサイトを見るにつけ、「自由だ！」ということを得意げに強調している。果たして自由であることが常にうれしいことなのか…？　オカタイ大企業の基幹系業務システムには「不自由さ」が求められることもあると思うのだけれど…。そう思うのは僕が古い考えだからだろうか…。

　まあ常に勉強だ。