昨日のエントリーにお返事

ぼくは更新したプラグインのみ、MANIFEST.MFのバージョンを上書きするのが本来の筋じゃないかなと思います。

その通りですねー。本来。
Eclipseほどの規模になれば、Ganymedeのリリース責任者とECF, Mylyn等のリリース責任者は当然異なりますので、同じバージョンに揃える方がコストが高く、リスクが大きいからこそ、こういう事になっているのでしょう。
ただ、Sabotterに関しては全コンポーネントが自分の配下にある為、そこまで厳密にやる価値も感じていません。更新されたプラグインのバージョン表記を上げ忘れるよりも、更新していないプラグインのバージョンを上げる方がリスクが少ない。ということで、この様な対処方法になっています。

ケースバイケースじゃないですか、ということで。

# qualifierについては、採用済みです。

trunkでチェックアウトする件は、「Find/Check out As」を選ぶとtrunk以下に存在するprojectを検索するのでそこまでうんこ！なことにはならないですよ。

なるほど。そういえばそうですね。存在には気づいていましたが、使ったことなかったなぁ。今度試してみよう。

そうそう。それでもまだ悩ましい点が一点。（上記の）一般的なtunkをチェックアウトする方式の場合、trunk内に新たなコンポーネントが作成された時、trunkを更新すれば、新しいコンポーネントが自動でチェックアウトされます。が、Eclipseの方式では、リポジトリをチェックしない限り、新しいコンポーネントが増えた事に気づかず、新コンポが依存しているコードを書き換えてエラーを起こしてしまう、という危険性もありますねぇ。避けられないものなんでしょうか。。。

Dolteng (覚えてますか？)

あーーーはい、すっげぇ覚えてますorz 今、色々な事に手を回し過ぎなのかなぁ。手が回らなくなってしまっています。現在のDoltengはGanymedeで動かないのも把握していますので、近々改修に入りたいと思っています。

ところで、Repositoryを移動したDoltengですが、旧reposでは Eclipse common プロジェクトのコードに対してsvn:externalでリンクが張られていたと思うのですが、新reposでは普通に生にコミットがされているようです。

自分が直せれば良いのですが、svn:externalの使用経験がない為、怖じ気づいていますｗ もしお手透きでしたら、対策をお願いしてもよろしいでしょうか。ってこういうことはseasar-devに流すべきかｗ

Team なんてメニューが出てくるということは，これは Package Explorer なんかで操作している？ コミットも同じ？

ああ、基本的に PackageExplorer からの操作です＞自分
周辺の人のコミット作業を見ていると、Synchronizeビューでコミットを行っているケースが意外に多いのにも気づいていますが、慣れの問題で、いつもPackageExplorerからのコミットを行っています。

部分的にコミットする事を考えると、そのリビジョンがコンパイルエラーを起こす危険性が高まると思い、なるべくシステム全体のコミットを行うように心がけているのですが…。なんか考え方間違ってるのかなぁ…。

コミットの差分が見られるというメリットに関しては、私はコミット前に、Compare with＞作業コピーからベース の操作で diff を確認してからコミットしています。