Eclipseでsvnに長い（といっても１万行未満）ソースをコミットしたらコリジョンが発生。
クリーンナップしてみると誰かがボクのソースを消したと表示される。
バックアップを取って、プロジェクトを取り直すと、そんなrevisonのログはドコにもない。
実は長いソースの保存が遅延し絶妙にバットなタイミングでファイルの差し替えが行われる際に発生する。
ソースエディターにはフォーマッタの他にFindBugsなどが満載しており、ソースファイルは文字通り引っ張りだこ。
にも拘わらず、このソースと云うリソースの競合管理なんて機能はなく、プラグインがただ順番に処理されるだけ。
残念だが今のファイルシステムは大容量のバッファリング機能があるし、VM上のデスクトップだったりすると、漫然と順番に処理しているだけでは、バッファをflush実行がドンドン後回しになり、もう我慢できないところまで来ると一気に物理デバイスに吐き出さるので、肝心のファイルが古いままビルドしてしまうこともままある。
それだけなら、もう一回ビルドしなおせばよいのだが、SubclipseつまりEclipseのsvnクライアントがそんなことになると、訳が判らない結果とイカレタ履歴が残るのでソース破壊を簡単にやってのけてしまうのである。
タダのEclipseが使えることで、Javaの開発環境は見かけ上リッチなクライアントになったけど、ソースが壊れているなんてことになる出来損ないの見かけ倒しの開発環境なのだ。
よく注意して使ってください。よく確認してください。とか云われるけど、Eclipseがダメダメなシロモノであることを経験的に知っているが、それを操作ミスと断定してしまっているのだ。
ま、Javaソースは書けるけど、jarファイルの作り方知らないとかも多い。ボクもEJBの仕組みは仮想化されてて実装がさっぱり見えないからよく判らない。
そんなJavaシステムがちゃんと動くのは中身をちゃんと知っている知らない誰かが知らないうちに直してくれているからだ。
そんな人がプロジェクトから抜けた途端。earファイルすらまともに作れなくなるのは当然。
もちろんEclipseも同じ。
もうかなり年月が経った。そろそろEclipseもMS-Windows並に中身がよく判らないシロモノになっているので、
そろそろ捨て時である。