暴風前夜のeclipse

「.metadata」は定期的にバックアップしとけ

eclipseを長く使っていると、ある日突然、起動できない、ビルドできない等のトラブルが時々発生する。原因の殆どは、ワークスペースフォルダ直下でeclipseを設定情報を管理している「.metadata」の破損。トラブった際は.metadata内のあのファイルをああしろこうしろと言った情報がWebに溢れているが、定期的に丸ごとバックアップしておいてズドンと上書くのが一番手っ取り早いです（当然、バックアップ取得以降の変更内容は失われますが）。

SVN管理化のJavaソースファイル名称変更後に発生した、同期化エラートラブルの記録

一般的なトラブルかどうか分からんが、一応記録しておく。

SVN管理化のJavaクラスの名称を、リファクタリング機能にて変更した。Javaの場合、クラス名＝ファイル名という決まりなので、必然的にファイル名も変更することになる。これにより、変更前のJavaファイルは「削除」、変更後は「新規」扱いとなり、それぞれコミットした。すると、それ以後、ファイル名変更をコミットしたメンバー（厳密にはworkspace？）以外の開発環境において、同期化エラーが発生するようになってしまった。

上記のトラブルは度々発生した。何が原因なのか結局わからなかったが、トラブル発生直前の操作内容を見聞すると、以下の共通点が浮かび上がってきた。

1. クラス名を変更した。
2. 変更するのにeclipseのリファクタリング機能を用いた。
3. 新規ファイル（クラス名変更後のJavaファイル）は、「バージョン管理に追加」せずに、いきなりコミットした。

これらを踏まえて、クラス名変更時の手順を以下のようにしたら、トラブルは発生しなくなった。

1. クラス名を変更する際は、リファクタリング機能は使わない。
   つまり、新名称のJavaファイルは新規作成、旧名称のは普通に削除。
2. 新名称Javaファイルは、まず「バージョン管理に追加」し、それからコミットする。

上記解決方法は別の人が調べて持ってきてくれたのだが、1・2どちらか片方だけではダメだったのだろうか。まあ「ダメだった」って言ってたからダメなのだろうが…一度自分で試そうとしたが、これ以上トラブル発生して作業が停滞するのもしんどかったので（てかプチ炎上中だったし）、実行に映さず。

ちなみに、そのリポジトリのルートディレクトリに対するアクセス権限が与えられていなかったのだが、関係あるのかな？

別リポジトリ管理化のリソースをコピペしてくる際の注意事項

ユーティリティ群など汎用的な部品は、別プロジェクトで作成したものをコピーしてくるという事はよくやると思うが（※１）、その際は「.svn」はコピーしないこと。どのリポジトリに接続するかという情報はこの中で管理しているので、「.svn」ごとコピーしてしまうと、同期化時に別のリポジトリに対する接続ダイアログが何度も表示されたり、「遮断」的なエラーが発生したりする。

ちなみに、TortoiseSVNのエクスポート機能を利用すれば簡単に削除できる。

※１
てかjar化しろって話か。