月別アーカイブ
検索

‘Subversion’ タグが付けられた記事

2011-06-11 : post-commit スクリプトを修正しました。

昨日の記事で紹介した、”Subversionのリポジトリをsvnsyncコマンド使ってミラーリングする”方法の追記です。

昨日は簡単に書くと、本家リポジトリのコミット完了後に分家リポジトリにsvnsyncを発行する、というところまでやりました。

今回は、分家サーバが稼働中のときだけ svnsync する、という処理を加えましょう。

続きを読む »

当サイトでは、そもそもがSubversion自体が「履歴機能付きのバックアップツール」という位置づけで紹介しています。

確かに最新ファイルは各ユーザの手元と、Subversionリポジトリ内に保管されているので、安心です。

では、過去の履歴はどうでしょうか?

大抵の場合は過去の履歴はSubversionリポジトリ内にだけしかありません。つまりサーバが壊れれば、過去の履歴は消えてしまいます。これでは魅力半減です。そこで・・・。

続きを読む »

Subversion では、外部のリポジトリにあるファイルやディレクトリを、まるでリポジトリ内にあるかのように扱うことができます。

この機能を使うことで、同じファイルを複数のプロジェクトで共有することができます。

設定方法

TortoiseSVN + 日本語パック を使って設定する方法を紹介します。

例えば、ディレクトリ Azalea の中に、他のプロジェクトで開発したプログラム MoodyBlues (これを外部項目といいます)を入れたい場合は、以下のように設定します。

  1. 外部項目を入れたいディレクトリを右クリックし、TortoiseSVN→属性 を設定する。
  2. New を押し、Property name から、”svn:externals” を選択する。
  3. Property Value に、”(参照したいリポジトリのパス)△(ディレクトリ名) “を入れる(△は空白)。
  4. OKボタンを押す。

一旦コミットしてから更新すると、外部項目として設定したファイルやディレクトリが取得できます。

リポジトリ内でもOK

参照したいリポジトリのパスは、自分自身の中でもかまいません。

その場合は相対パスでも指定可能です。また、^ で始めれば「自分のリポジトリのルートディレクトリから」指定できます。

Redmine や Subversion の紹介をしてきましたが、慣れない方にはこれらの設定はなかなか難しいものです。

いろいろ調べればできないことはないのでしょうが、おそらく気の遠くなるような時間と労力が必要になります。本来の仕事に時間を使う方が、絶対に得策です。

でも、Redmine も Subversion も、あれば絶対に便利で、効率アップ間違いないのです。

矛盾

そうです。どのソフトウェアも、ぜひ使って欲しいものばかりです。

その一方で、設定するためには膨大なノウハウと時間が必要なので、安易に「使ってみて」とは言えませんでした。

そこで新製品

そこで、新製品を開発しました。その名も Momiji(もみじ)。

これは、CD-R と 外付けUSB-HDD からなる製品です。

古いパソコンでもいいので、Momiji を動かせば、いろいろな機能を持ったサーバに生まれ変わるのです!

例えば、こんな機能を持っています。

  • プロジェクト管理(Redmine)
  • バージョン管理(Subversion)
  • ネットワーク 共有フォルダ(Samba)
  • ウェブサーバ(Apache2)
  • 世代管理バックアップ(Moody Blues)

使い方

使い方はとても簡単です。

CDドライブから起動できるパソコンに、Momiji の CD と USB-HDD をセットし、電源を入れてください。

あとは、起動するまでしばらく待てばOK。

ところで動作環境ですが、メモリ256MB あれば、なんとか動きます。

開発時は、2002年発売のノートパソコン(Mobile Celeron 1.06GHz、メモリ256MB)で動かしていました。

さて、そうこうしているうちに、起動しました。

他のパソコンから、ネットワーク経由で Momiji が見えれば準備完了です。ネットワークごしに、各機能を使えます。

こんな使い方も・・・

先日、取引先から「パソコンが起動しなくなったが、なんとかデータだけでも取り出せないものか」と相談を受けました。

そこで、Momiji の登場です。

パソコンのハードディスクに入っているOSは起動しなくても、CD からの Momiji はちゃんと起動しました。

Momiji はハードディスクにアクセスすることもできますし、Windowsの共有フォルダにもアクセスできます。

この機能を使って、無事に壊れたパソコンからデータを救出することができました。

まとめ

いろいろな使い方ができますが、メインはやっぱり「便利な機能を簡単に使える」ということ。

CD と USB-HDD をセットして電源を入れるだけです。

先日、Subversion のリポジトリアクセスを SSL 対応にする手順を紹介しました。

SSL接続のみ許可する

さらに、/etc/apache2/conf.d/subversion.conf ファイルの記述に SSLRequireSSL の行を追加することで、

<Location /svn/[リポジトリ名]>
        DAV svn
        SVNPath /var/lib/svn/[リポジトリ名]
        AuthType Basic
        AuthName "Subversion Repositries"
        AuthUserFile /var/lib/svn/itpk/conf/.htpasswd
        Require valid-user
        SSLRequireSSL
</Location>

このリポジトリには、 Apache2 経由では SSL通信でしかアクセスできなくなります。

こうしておくことで、設定ミスで(または面倒だからという理由で)通常のHTTPで通信することがなくなるので、安全性が高まります。

Redmineからリポジトリへアクセス

ところで、Redmine では プロジェクトにリポジトリを対応付けられます。

とてもよくできた機構で、どのチケット(=Redmineでは1つの作業をチケットで管理する)のために、どのファイルのどこを変更したのかが分かるのです。

で、Redmineでこの機能を使うためには、プロジェクトの設定で リポジトリを指定する必要があります。

ところが、SSL通信を使って “https://…” を指定すると、Redmineからはリポジトリにアクセスできません。

どうも、SSL通信で失敗しているようです(正式な証明書を使用していないせいかもしれません)。

普通に “http://…” ならばアクセスできるのですが、Redmine のためだけに抜け道を用意するのは、躊躇(ためら)われます。

社員に何の悪気がなくても、その抜け道を使ってしまえば、悪意のある盗聴者に重要なファイルが漏れる恐れがあるからです。

解決策

解決策は非常に簡単でした。

Redmine に リポジトリ の設定をする際には、http 以外にも file や svn といったプロトコルを使って URL 指定をすることができます。

svn プロトコルは、svnserve というプロセスが動いていないといけないのですが、 file はファイルアクセスができればOKです。

我がITPKの社内サーバでは、Redmine が動いているマシンに、Subversion リポジトリの実体があるので、もちろんファイルアクセス可能です。

なので、 file:///var/lib/svn/[リポジトリ名]/ を指定することで、SSL通信だけに制限しても、Redmine からリポジトリアクセスできます。

もちろん、Redmine はローカルファイルアクセスをしているだけなので、盗聴の恐れもありません。

「2010年は定時で帰ろう」シリーズの記事です。お時間がありましたら、関連記事も合わせてお読みください。

今回は「資料があちこちにあって、探すのに時間がかかる」のをなんとかしよう、という話です。

生きるとは探すこと・・・?

半年ほど前の「ガイアの夜明け」で、”片付け士”が紹介されていました。

この中で興味深かったのが、仕事中に物を探している時間についての話です。なにせ半年前なので曖昧な記憶ですが、人は約12分の1の時間を「何かを探す」のにあてているそうです。

この数字、曖昧な記憶にしては、それなりに的を射ていると思いませんか。

例えばネット検索でこのページにたどり着いた方、目的の情報は得られたでしょうか?なかったとしたら、さらに探す時間が増えるわけです。

ネット検索は知りたいことを探すのだからまあ建設的ですが、うまく整理しておけば探さなくて済むものを探すのは時間の無駄ですね。

資料は探せますか?

書類や在庫の整理はちょっと置いておいて、パソコンで作成した資料についてです。

パソコンで作成した資料は、たいてい”ファイル”という形で保存します。

人によって様々(まずここが問題)ですが、プロジェクト名のフォルダを作り、その中に「企画書」だとか「設計書」のような種類を表すフォルダを作り、…。としますね。多分。

そして、メールです。以前の記事にも書きましたが、何でもかんでもメールで送られてくる時代です。ほら、せっかくフォルダを上手に作っても、資料がファイルとメールに別れてしまいました。

「ファイル検索しても見つからない」と思ったら、メールに書いてあった、なんてことはありませんか?

古い資料は消す・・・わけにはいかない

フォルダ(またはディレクトリ)という仕組みは、とてもよくできた仕組みだとは思うのですが、「時間軸」という視点が欠けていると思います。

例えば、”企画書.doc” を修正したとき、そのまま上書き保存すれば、古いファイルは消えてしまいます。(弊社では、これを手軽に解決する Moody Blues という製品を提供しております)

古い状態も残したいと思ったら、古いファイルを”企画書_org.doc”という名前にでもしておくか、新しく保存する時に”企画書2.doc”とするなどです。

これを続けていくと、似たファイル名がたくさん並んでしまい、「本当はどれがオリジナルなのか」「いったいどれが最新版なのか」が分からなくなってしまいます。

「時間軸が欠けている」という意味が伝わったでしょうか?

Redmine で解決!

さて、Redmine の登場です。

Redmine では、1つのプロジェクトごとに、1つのウェブサイトがあるようなイメージです。

そのウェブサイトの中には、進捗管理のページや、掲示板、ブログ、ファイル保管庫などの機能が入っています。

メールはもちろん使ってもかまいませんが、重要なメールはRedmineの掲示板にそのまま書き込んだり、文書として登録してしまってください。

作ったファイルはファイル保管庫に置くのもいいでしょう。

(登録するプロジェクトさえ間違えなければ)検索機能で即座に資料を探すことができるのです。

Subversion で解決!

大雑把に言うと、フォルダに時間軸を持たせることができます。

普通に見ていれば、現在のファイルが見えます。

ところが、過去の好きな時点(リビジョンと言います)を指定すれば、(消してしまったファイルやフォルダも)その時の状態で見ることができてしまうのです。

だから、安心して古い資料は上書きしたり削除できるのです。

しかも、それぞれのリビジョンにはコメントを残せるので、「概要だけ作った」「一通り完成した」「社長の承認を得た」「顧客に提示した」「顧客の要望を取り入れた」…というように入れておけば、後から「最初に見せてもらった時のグラフだけちょうだい」なんて言われても、慌てずに済むのです。

よく「掃除とは捨てることだ」と言われますが、ファイルに関しても同じこと。不要なものは捨てた方が、必要なものを見つけやすいのです。

それでいて、Subversion があれば、捨てたファイルも取り戻せるんです。

まとめ

資料を探すのには時間がかかります。

資料を見つけやすい状態に保つためには、労力が必要です。

Redmine や Subversion は、その労力を大幅に軽減してくれます。

Subversion で管理しているリポジトリを、2つに分割した時の作業メモです。

2つに分けた理由は、アクセスできるユーザを分けたかったため。それぞれのパスに制限をかけるのに手間が掛かりそうなので、いっそ2つに分けることにしました。

元リポジトリのダンプを作成

まず、元リポジトリのダンプファイルを作ります。

# svnadmin dump /var/lib/svn/[元リポジトリ名] > /tmp/dumpfile

このファイルには全ファイルの全リビジョンの情報が書かれます(なので、それなりの時間とサイズになります)。

ちなみに、このファイルがあれば、元リポジトリを復元できるので、バックアップとしても使えます。

不要なファイルの情報を取り除く

# cat /tmp/dumpfile
        | svndumpfilter exclude [取り除きたいパス] (複数指定可)
        > /tmp/dumpfile1

「取り除きたいパス」とは、新しく作成するリポジトリには入れたくないファイルのパスのことです。リポジトリのルートフォルダからの相対パスで指定します。

逆に、

# cat /tmp/dumpfile
        | svndumpfilter include [入れたいパス] (複数指定可)
        > /tmp/dumpfile2

とすれば、「入れたいパス」のファイルだけが、リポジトリに入ります。

つまり、上記2つのコマンドで、元リポジトリの中身が dumpfile1 と dumpfile2 に分けられたことになります。

新しいリポジトリを作成

普通に作成して、ディレクトリの所有者を apache にします。

# svnadmin create /var/lib/svn/[新リポジトリ名]
# chown -R apache:apache /var/lib/svn/[新リポジトリ名]

ダンプから新リポジトリへ

最後に、不要ファイルを取り除いたダンプファイルから、新リポジトリへインポートします。

# svnadmin load /var/lib/svn/[新リポジトリ名] < /tmp/dumpfile1

この、「2010年からは定時で帰ろう」シリーズの記事は、実は Redmine という OSS(オープンソースソフトウェア) の紹介記事です。

これからも、この Redmine の紹介記事を書いていきますが、その前に一つだけ気に留めておいて頂きたいことがあります。

それは、ソフトウェア開発者以外の方にとっては「Redmine は一部の機能だけでも魅力的です」ということです。

Redmine はソフト開発者だけのもの?

Redmine は、バグトラッキングシステム というジャンルに分類されます。

これは、ソフトウェア開発でバグ(欠陥)の修正を効率的に行うためのシステムで、バグ報告から修正版ソフトウェア公開まで、非常に幅広い機能を持っています。

そして、おそらくこの記事を読んでくださっている方のほとんどは、「バグトラッキングシステム」なんて必要ない方だと思います。

しかし、私たちはそれを承知の上で、なおも Redmine を薦めたいと思っています。

なぜならば、(ソフトウェア開発以外の)多くの職場でも、Redmine の機能は役立つものだからです。

「課題」

Redmine では一つの仕事を チケット という名前で呼びます。

これがソフトウェア開発では、修正するべき「バグ」であったり、作るべき「機能」であったりするわけです。

Redmine を使った作業の進め方は、基本的にこのように進めます。

  1. 報告者がチケット(=バグ、機能)を登録する
  2. リーダーが担当者を決める
  3. 担当者が作業をして、チケットを更新する
  4. リーダーが作業終了(=バグの修正、機能の追加)を確認し、チケットを終了する

さて、このチケットを「課題」と読み替えてみてください。

  1. 報告者が「課題」を登録する
  2. リーダーが担当者を決める
  3. 担当者が作業をして、「課題」を更新する
  4. リーダーが作業終了を確認し、「課題」を終了する

いかがでしょうか、これならばソフトウェア開発の現場でなくても通用すると思いませんか?

実際に我が ITPK では開発以外の作業についても、 Redmine を使っています。

例えば、、、

  • 年賀状印刷
  • 買掛金/売掛金の処理
  • 電話料金の問い合わせ
  • プリンタの購入計画

など。

全ての仕事を Redmine で管理することのメリットは、「漏れがなくなる」ことです。

優先度が低い仕事であっても、常に作業リストには並んでいるので、「忘れ去られる」ということがありません。

仕事の計画を立てる際に、(後回しにするにしても)一旦目に入るので、その作業があるという前提で計画を立てられるのです。

「情報共有」

議事録をRedmineで一元管理

議事録をRedmineで一元管理

詳細は次回以降に書こうと思っているので概要だけ紹介します。

チームメンバー同士の情報共有はどのようにしていますか?

直接会って話せれば、かなり微妙なニュアンスまで共有できますが、なかなか時間が合わないという欠点があります。また、伝わったと思ったのが錯覚だった、なんてことも。一番の問題点は、記録が残らないことではないでしょうか。

最近では、情報はメールでメンバーに送る、なんていうことも一般的に行われているようです。

でも、メールは非常に便利で手軽なだけに、他の用途にも使われますから、きちんと整理しておかないと、読みたいメールが埋もれてしまいがちです(メールって検索しにくいんですよ)。

それと、後から参加したメンバーが過去の情報を読めない、という欠点も大きいです。

Redmine では、チームメンバーの情報共有のために、「ニュース」「フォーラム」「文書」「Wiki」という機能があります。

どれも似ているので、どれを使ってもOKです(一般的にも使い分けの明確なルールはないようです)。

とにかく、仕事に関する情報は、全てまとめて Redmine に登録してしまうのです。整理の苦手な人は書き込むだけで、後は整理上手の人が分類する、なんてのもいいでしょう。

我が ITPK では、

  • 頻繁に変更される事柄 → Wiki
  • 議事録 → 文書
  • 定型業務の作業手順 → 文書
  • ディスカッション(雑談?) → フォーラム

という具合に使っています。

「更新履歴」

ファイルの更新履歴

ファイルの更新履歴

もう一つだけ。とても便利で、ソフトウェア開発には必須システムなのに、それ以外の業種では全然使われていない機能を紹介させてください。

それは、バージョン管理システム です。

バージョン管理システムとは、ファイルの「更新履歴を管理」するためのシステムです。

皆さんの職場でも、見積書や企画書、報告書などの文章を、Word や Excel などで作ることがあると思います。

さて、このファイルを複数の人が編集する、なんていうことはありませんか?

過去に私にも経験があるのですが、このようなことをしていると、たいてい

  • 誰かが変更したのに気付かず、別の変更で上書き保存してしまう
  • 誰かが変更したみたいだけど、何を変えたのか分からない
  • 誰かが変更したらしいが、変更したファイルを送ってこない

といったトラブルが発生します。

しかし、バージョン管理システムを使用することで、

  • 複数の人の変更を合わせる(マージする)ことができる
  • 複数の人が同時に変更できないようにも設定できる
  • いつ、誰が、なぜ、どのような変更をしたのかが分かる
  • 他の誰かが変更したファイルを、いつでも取得できる
  • いつでも過去の好きな状態に戻すことができる

我が ITPK では、Redmine に Subversion というバージョン管理システムを連携させて使用しています。

実はこの Subversion は、ただ単にファイル共有機能だけでも、非常に便利なのです(詳細は今後の記事で紹介していきます)。

まとめ

Redmine や Subversion は、一部の機能だけでもとても魅力的です。

特にその “一部の機能” は、ソフトウェア開発者以外の方にこそ使ってもらいたい機能です。