Subversion 1.6 では正常に機能していたワークフローが、1.7 では機能しなくなりました。
私のコードは、ラップトップ (Mac) 上の Linux 仮想マシンに存在します。コードを編集するには、Samba 経由でディレクトリをホスト マシンにマウントし、Eclipse と Subclipse を使用します。
SVN 1.6 では、Linux コマンド ラインで「svn スイッチ」を実行でき、Eclipse はプロジェクトを更新した後に変更を認識します。
SVN 1.7 では、これは当てはまりません。svn スイッチの後、Eclipse は手動で更新した後でも古いブランチを使用していると認識します。これは単なる視覚的な問題ではなく、コードをチェックインしようとすると、古い (間違った) ブランチに送られます。
なぜこれが起こっているのですか？解決策はありますか？
OS 間および/またはネットワーク共有を介した作業コピーの共有は、推奨またはサポートされている構成ではありません。1.6 で動作するように見えたかもしれませんが、時間の経過とともにうまく動作しなくなる可能性があるという警告が常にありました。
これは、作業コピー形式がプレーン ファイルではなく SQLite に依存するようになるにつれて、ますます真実になっています。
解決策: これを行わないでください。作業コピーをクライアントに対してローカルに保ちます。
コミット自体は Subversion API を介して行われ、「送信」先を API に指示しません。内部的には、API は作業コピーのメタデータから読み取った内容に基づいて決定します。正直なところ、このシナリオはとてつもなく現実的ではないように思えます。実際にコミットしようとしましたか、それとも UI の指示に従いますか?
SVN 1.7 には、Eclipse の外部で行われた変更が Eclipse の内部に表示されない作業コピー レイアウトがあります。これらのシナリオに対処するための明示的なオプション ([チーム] > [クリーンアップ/更新]) を追加しました。これにより、通常は更新を引き起こし、SVN メタデータの読み取りを強制する Eclipse のトリガーがバイパスされます。
以前の SVN リリースでは、作業コピーのメタデータがすべてのフォルダーに存在していたため、通常の Eclipse リソースの更新は、メタデータの更新時に常にトリガーされていました。