svn log -q /tmp/svnlog
grep nobita /tmp/svnlog | awk '{print $1}' | sed s/r// | while read line ;do ; svn ps --revprop -r $line svn:author gian $REPO ; done
ワンライナーと言いながら２行のコマンドになってしまいました。
何かのお役にたてば幸いです。
setTimeout(function(){alert(1)}, 1000); // 1秒後にalertvar say = function(){ alert('hello');}
setTimeout(say, 1000); // 1秒後に'hello'と表示「ケツカンマ問題」
— Sotaro KARASAWA© (@sotarok) May 2, 2012
var list = ['a' , 'b', ];
var obj = { a : 1, b : 2, }var x = {
a : 1,
b : 2,
c : 3 // ←カンマつけない
}
SELECT table_schema
, SUM(data_length+index_length) /1024 /1024 as MB
FROM information_schema.tables
GROUP BY table_schema
ORDER BY SUM(data_length+index_length) DESC
ファイル・レベルのプリアロケーション データベースやコンテンツ・ストリーミングなどといった特定のアプリケーションでは、ファイルが隣接するブロックに保存されることを大前提とします (ドライブの連続ブロックに対する Read 操作の最適化を活用するため、そして Read コマンド対ブロックの比率を最大限にするためです)。ここでいう「新しいシステムコール」というのが、"posix_fallocate"というものです。
エクステントによって隣接するブロックのセグメントを提供することもできますが、もう 1 つの強力な方法は、必要なサイズの隣接ブロックからなる非常に大きなセクションを事前に割り当てることです (かつて XFS で実装していた方法です)。
ext4 ではこの方法を実装する手段として、指定したファイル・サイズを事前に割り当てて初期化する新しいシステム・コールを使用します。
こうすることで、事前に割り当てたセクションに必要なデータを書き込めば、そのデータに対する Read 操作のパフォーマンスを優れたものにすることができます。
うちではext3でtook 6.443 secsですけど。ほんとにファイルシステムのせいなのかな。 RT @yukihiro_matz: link: MongoDBをext3で使ったら死んだ - DQNEO起業日記 dqn.sakusakutto.jp/2012/04/mongod...
— Kenn Ejima (@kenn) April 25, 2012
@DQNEO 余談ですが、Mongoのバージョンが古くないですか？2.0系でテストしてみてはどうでしょう？そもそも通常処理もグローバルロックが軽減されて激速になりましたよ。
— Kenn Ejima (@kenn) April 25, 2012
ここで示唆している事が事実なら、2GB超えのsparseファイルを作る時に本当に領域作ったりえっちらほっちらしてるって聞こえるんだけどもホントかいな：MongoDBをext3で使ったら死んだ - DQNEO起業日記 dqn.sakusakutto.jp/2012/04/mongod...
— 這いよるMIPS驟雨トホテプ (@syuu1228) April 25, 2012
@masanork 一つ前のエントリを参照してください。ext3はサイズの大きいファイルのアロケーションに弱いという欠点があるそうです。
— Yukihiro Matsumoto (@yukihiro_matz) April 25, 2012
