hg2svn.tailor, BCB.PITA++;

dev-util/tailor．．．使い方がヨクワカラン． :P
subversionのレポジトリ構成を理解していない所為だなー．
多分，どこか間違ってるハズ．
[dev-util/tailor... it makes me messy. :P
Well, that must depend on my ignorance about
subversion repository structure and scheme or so.
Some bad things are...]

[DEFAULT]
verbose = True

[project]
target = svn:default-target
start-revision = INITIAL
root-directory = /tmp/commit_dir
state-file = hg2svn.tailor.state
source = hg:default-source
subdir = svn_co
patch-name-format = 

[hg:default-source]
module = /
repository = /usr/local/portage

[svn:default-target]
module = /trunk
repository = file:///tmp/commit_dir/svn_repos

例のBCBなプログラム，なめてかかっていたら色々面倒な事やっているっぽい．
「制限時間付き待ち行列の各要素に対する運用上問題の無いハッシュ関数」？
グローバル変数のカウンタを回しつつ，似非mutexでロック．
現場でハッシュの値域が足りなければ，
カウンタの上限を上げてcut and tryって，美しくねぇー． :P
[The stupid BCP progs, that makes me really cofuse.
"An operational well-evaluated hash function
for event queuing which has a time limimt"？
Its implementation is,
* Count up crappy global var with a defined maximum value.
* Lock it with dirty mutexing to prevant accessing conflicts.
* If the rage hash value was too narrow, redefine its maxmum value.
For define that maximum value, to cut and try is the way to evaluation.
Bleh, it makes me.code.karma--; :P]

あと，双方向リストのpush/pull/findをdead-lockしない様にに実装せねば．．．
やべー，納期がー，あー，納期がー． :P
[And then, it required no dead-locking push/pull/find
functionalities for bi-directional list...
Oh, well, there're some dead-locks, here's some dead-lines. :P]