CVSとSubversionとBazaarとブランチ
「ブランチ」（branch）は、バージョン管理の上で重要な概念であるが、バージョン管理システムによって、その具体的な意味（実装）は全くことなる。
- CVS
- cvs tag -b により生成される、特定のリビジョンから分岐したリビジョンの列。
- Subversion
- svn copy により生成されたディレクトリ（もしくはファイル）のうち、コピー後に変更が加えられてcommitされたもの。もしくは、一般的なリポジトリ構成における、trunkをbranches以下にコピーしたもの。
- Bazaar
- bzr initにより生成される（もしくは、既存ブランチからbzr branchにより生成される）、バージョン管理されたディレクトリ。リビジョンの集合。
Bazaarのチュートリアルを読んで全力で混乱し、そういやCVSからSubversionに移った時もハマったなー、ってことを、ふと思い出したのでメモ。CVSからSubversionに移ったときは、「ブランチを作る/取ってくる機能」というものが無くなり、運用上の存在になっていたので混乱した。一方、今回は、「ブランチ」＝「枝」＝「幹から分かれたもの」という本来の意味から離れ、操作単位程度の意味で使われているので混乱した。これは、Bazaarの特徴である、"pull"によって得られるのがリポジトリ全体じゃなくてブランチだということから、逆定義した感じのような気がする。gitだとどういう定義なのか気になるけど、気力が尽きてきたからもういいや。
因みにここまで全部自分理解なのでご注意を。
なお、Bazaarは用語集があるので、まずそれを見ておくと混乱が少なそうに思う。Subversionユーザ向け解説もあるが、書きかけでアテにならないのが残念。
2011-05-05 修正
bzr branch でも（当然ながら）ブランチは出来ますね。
そのポイント、失効させるくらいなら募金しませんか？
クレジットカードなどのポイントや、航空会社のマイルって、そこそこサービスを使い込んで、まとまったポイントにならないと使い物にならないことが多いですよね。で、微妙なポイント数の間に失効を迎えてしまう、と。私みたいに、単純に手続きが面倒で消え去ってる人もいるかもしれません。
そんなあなたに耳寄りな話。そんなポイントが震災の義援金として募金できます。消えてしまったり、大して欲しくない微妙な景品と交換するくらいなら、世の中に役立てましょう。
私が直接確認したのは、三井住友VISAカード、ビューカード、ドコモポイント、Tポイント。他にも、JAL, ANAのマイルなんかもいけるみたいです。
すこしググってみたら、まとめてるサイトもありました。
http://matome.naver.jp/odai/2130007492348053301
結構色んなサービスが、ポイントからの募金を始めてます。皆様も消えるだけのポイントがあるなら、募金に回してみてはいかがでしょうか。
SPINのウェブサイトでバグを見つけた
なんかうろうろしてる
プログラミングとかDSLとか
各所で話題になっているので反応してみる．
南米発のツールがIT業界に与えるインパクト | 日経 xTECH（クロステック）
プログラマはもう要らない？、南米発のアプリ自動生成ツール | スラド IT
まぁ普通に解釈すれば要するにコード生成までサポートしたDSLなツールであり，それほど珍しいものでもない．…という書き方はいささか醒めすぎの感はあるが，それでもはやりこの文章は煽りすぎだろうと思う．
私は概ね/.のこのコメントに同意で，このツールが世界を変えるか，というと，そんなことは無いと思う．このツールが数多くのプログラマを廃業に追い込めるなら，MetaEditやRhapsody，もしくはVisual Studioが既にそれを成し遂げている．
この手のツールは，ターゲットのドメインを広げれて記述能力を高めれば高めるほど，ツールが難解になり，生成されるコードも質が低くなる傾向にある．ドメインを絞れば分かりやすくなり生成コードも最適化しやすくなるが，実現出来ることが限られる．両立させようとするとツールが高価になる．記事からは，バックエンドは上手く出来ている一方で，フロントエンドは実用レベルに無い，ということが読み取れる．
とはいえ，これだけおおっぴらに取り上げられるからには，企業情報系にターゲットを絞り，うまくバランスを取って設計されたツールなんだろうと思う．一応チェックしとくべきか．
DSLツールは自動コード生成とかコーディングレスとかいう言葉をよく煽り文句に使うが，コーディングは不要になってもプログラミングという行為そのものが無くなることは無い．レイヤーが上がるだけである．しかし，設計レベルの問題が実装レベルまで持ち越されて何を作ってるのか分からなくなると言った，ありがちな混乱を防ぐことが出来る．個人的には，コード生成そのものより，役割分担がはっきりして混乱を防げることの方が，効果としては高いんじゃないかと思う．
それはともかく，しかしなんだ，なんていうか，クマー (AA略
JAXAに愛を! 具体的には予算を!
盛り上がって終わりで，研究開発の流れが断ち切られるなんて，切ないことになりませんよう．
ともかく，はやぶさ帰還＆カプセル回収おめでとうございます．
mozcをFreeBSDでビルドしようとして挫折
Google日本語入力のOSS版であるところのmozcをFreeBSDでビルドしようとして普通に挫折し，予告通り不毛な週末を過ごしたので，そのメモ．っていや本当に全部つぶしたワケじゃないけど．よい子は真似するの禁止．
LinuxBuildInstructionsに従いコードを入手し，Compilation に移る前に色々と修正する．
makeとしてgmakeを使うようにしとく
% export BUILD_COMMAND=gmake
QTDIRなる環境変数があるので，よく分からんけど /usr/local を指すようにしとく
% export QTDIR=/usr/local
何かしらんけどデフォルトの g++ じゃ駄目だったので，LLVMのg++を使う*1．ついでにgccもLLVMのにしとく．
% export CC=/usr/local/bin/llvm-gcc % export CXX=/usr/local/bin/llvm-g++
ビルドスクリプトがFreeBSDをLinuxとして認識するようにしとく．build_mozc.py 編集
def IsLinux(): """Returns true if the platform is Linux.""" - return os.name == 'posix' and os.uname()[0] == 'Linux' + return os.name == 'posix' and os.uname()[0] == 'Linux' or os.name == 'posix' and os.uname()[0] == 'FreeBSD'
インクルードディレクトリなどの設定．gyp/commons.gypi編集して追記*2
'include_dirs': [ (略) + '-I/usr/local/include' ], +'ldflags': [ + '-L/usr/local/lib' +],
const charとcharでハマってるので，base/iconv.cc 編集*3
void IconvHelper(iconv_t ic, const string &input, string *output) {
(略)
- char *ibuf = const_cast<char *>(input.data());
+ const char *ibuf = const_cast<char *>(input.data());
(略)
- if (iconv(ic, reinterpret_cast<char **>(&ibuf),&ilen, &obuf, &olen)
+ if (iconv(ic, &ibuf, &ilen, &obuf, &olen)
(略)
}PTHREAD_MUTEX_RECURSIVE_NP が使えるのはLinuxだけみたいなので，PTHREAD_MUTEX_RECURSIVEに置き換える．base/mutex.h 編集
#ifdef OS_LINUX - #define PTHREAD_MUTEX_RECURSIVE_VALUE PTHREAD_MUTEX_RECURSIVE_NP + #define PTHREAD_MUTEX_RECURSIVE_VALUE PTHREAD_MUTEX_RECURSIVE #endif
で，Compilationの手順を追っていくと，以下のエラーで落ちる．
Running: gmake -j4 BUILDTYPE=Release build_tools
out/Release/.deps/out/Release/obj.target/gen_suggestion_filter_main/prediction/gen_suggestion_filter_main.o.d:9: *** タ ーゲットパターンが `%' を含んでいません. 中止.
Traceback (most recent call last):
File "build_mozc.py", line 586, in <module>
main()
File "build_mozc.py", line 576, in main
BuildToolsMain(original_directory_name)
File "build_mozc.py", line 541, in BuildToolsMain
BuildMain(original_directory_name)
File "build_mozc.py", line 520, in BuildMain
BuildOnLinux(options, targets)
File "build_mozc.py", line 393, in BuildOnLinux
target_names)
File "build_mozc.py", line 312, in RunOrDie
'==========']))
__main__.RunOrDieError:
==========
ERROR: gmake -j4 BUILDTYPE=Release build_tools
==========見たところ自動生成されたMakefile (正確にはインクルードされる依存関係記述）が壊れているらしい．どのタイミングで誰が生成してるのか全く不明なので，ここで挫折．個別対処しようにも，どう直せば良いのかよく分からない上，同様に壊れてるファイルが大量に存在するし．ということで続きはまた来週 *4．
