From: Urabe Shyouhei <shyouhei@...>
Date: 2007-01-07T00:43:09+09:00
Subject: [ruby-dev:30098] Re: version.h maintenance

卜部です。

SASADA Koichi wrote:
> a) version.h の更新のたびに リビジョン番号が上がるのは好ましくないかも
> b) 変更があった場合、そのリビジョンでは version.h の日付は以前に
> version.h の更新があったときのものになる
>   

a)のほうは「気にするべきではない」と思います。リビジョン番号なんてじゃん
じゃん増えて困るもんじゃないと思います。b)はたしかに問題なような気がしま
すね。

> 1. version.h をコミッタが変更してからコミットする
>
> 　これは、version.h を変更してからコミットするようにコミッタに負担を強い
> る方法です。ただ、コミッタの環境でコマンド一発で version.h を更新できる
> ようなツールを作るのは難しくないとは思います。
>
> 　コミット時、サーバ側で version.h の変更が無ければコミットさせないよう
> にフィルタを作ることも可能だそうです。
>   

これ(version.hの変更がなければ拒否)は困りませんか?たとえば一日に二回コ
ミットするときとかに。

> 2. version.h はチェックアウトしてから作る
>
> 　日付は ChangeLog の行頭などに $Date$ などを加えておくことで、それを解
> 析してから version.h を作成するルールを make に加えることが可能です
> （YARV では revision をそうやって作っていた）。ただし、Subversion ではな
> く、他のツールを使って管理していたりすると、ちょっと変になりそうです。
>
> 　tar ボールを作るときには、version.h を作っておいてから、ということにな
> ります。
>   

tarを作るのも自動化するのがいいかもしれませんね。

> 3. version.h から日付情報を消す
>
> 　いっそ、日付やめてリビジョン番号だけの表記にするとか（現実的じゃない
> か）。開発者の場合はそれだけでもいいかも。
>   

trunkがそうなるのは構わないと思いますが、互換性がなくなってぎゃっという
人は多そうな気がします...

> 4. 今までどおり後からコミット
>
> 　従来どおり、コミットがあってから version.h を更新。1 とあわせ技にする
> のはありなのかも。
>
>
> 　3つあげてみたんですが、他にもあると思いますので、何かありましたらご指
> 摘下さい。
>   

結局post-commitでひっかけてversion.hを自動更新するというのは技術的に困難
だったっていう結論なんでしょうか。だとするとありそうな選択肢としてはcron
で毎日一回version.h更新スクリプトを走らせるようにするとか...