サブクリップは、パスが作業用コピーではないことを訴えています”ワークスペースを移動した後
質問
最近、Eclipseワークスペースディレクトリを移動しましたが、ファイルを開くたびにSubclipseからメッセージが表示され、コンソールに次のようにダンプされます。
パスは作業コピーディレクトリではありません
svn: ' [元の(移動前)ディレクトリパス] 'は作業コピーではありません
そのようなファイルまたはディレクトリはありません
これは、ファイルの履歴を明示的に表示しようとしたときにも発生します。これは、SVNのクリーンアップ、Eclipseの終了および再起動などで維持されます。
更新、チェックイン、チェックアウトなどはすべてうまくいくようで、Tortoiseはまったく文句を言わないので、明らかにSVNメタデータではなく、Subclipse固有のメタデータです。この壊れたメタデータを吹き飛ばす方法を教えてもらえますか?
追加して編集:" Team>切断"続いて" Team>共有"問題を解決しません。
再度編集して追加: .metadata
ディレクトリ全体と、プロジェクトパスの1つを古いパスの一意の要素にgrepしましたが、できません .metadata / .log
(エラーメッセージ自体)およびいくつかの古いFindbugsの警告以外の場所で見つけてください。とてもいい。
解決
ワークスペースディレクトリ外のプロジェクトで、javahlでsubclipseを使用すると、同じエラーメッセージが表示されていました。 svnKitに変更することで問題が解決しました。
他のヒント
.syncinfo
ファイルを削除する必要があります。これは(ほとんどの場合)Eclipseを閉じたり開いたりすることで簡単に行えますが、次のように手動で行うこともできます。
キャッシュを削除するには、Eclipseを閉じます。キャッシュは次の場所に保存されます。
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects/PROJECTNAME/.syncinfo
したがって、
で.syncinfo
という名前のすべてのファイルを検索して削除できます。[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects
この記事から引用: http://subclipse.tigris.org /ds/viewMessage.do?dsForumId=1047&dsMessageId=868799
"チームをやった->クリーンアップ"この正確なエラーはなくなりました!マシン間を移動し、パスが同じではなかったため、このエラーも発生しました。
Eclipse 3.6およびSubversion 1.6プラグインの使用。
2016年の更新: Eclipse 4.5.2およびSubclipse 1.10でも引き続き完全に動作します
追加するために編集:いいえ、話が早すぎました。これでは修正されません。一部のファイルでは問題が発生していないようです。
次は問題を解決するようです:
- チーム>切断します。
- Eclipseを終了します。
-
.metadata / .plugins / org.tigris.subversion.subclipse。*
を削除します。 - Eclipseを再起動します。
- チーム>共有します。
古いパスが実際にプラグインの設定にどのように保存されているかはわかりませんが、どこかにあったはずです。絶対パスを保存することはSubclipseの一種の哀れなことですが、明らかにそうです。
これに提出されたバグ、または少なくとも同じエラーメッセージ。コンテキストなし。 50セントは拒否されると言っています。
異なるソリューションには多くの原因があると確信していますが、ダンウィルソンのブログ。問題のフォルダーをワークスペースから削除し(おそらく新しいコンテンツがある場合は保存する)、更新(Subversionにフォルダーを再作成させる)してから、コンテンツをワークスペースの新しいフォルダーに戻します。
Eclipseでケースを DAO
から Dao
に変更してクラスの名前を変更しようとすると、エラーが発生しました。
Dao2
のような名前に変更する必要があり、その後 Dao
に名前を変更できました。
私のために働いたもの: 「リファクタリング-名前変更」を行うプロジェクト=>その後、もう一度名前を変更して元の名前に戻します。
これ以上情報なしで言うのは難しい。
ワークスペース全体またはコンテンツのみを移動しましたか?
また、新しいワークスペースを最初から作成して、プロジェクト全体をもう一度チェックアウトすることもできます。
別の方法として、.metadataディレクトリを削除して、File->を使用してプロジェクトを再リンクすることもできます。インポート->既存のプロジェクトをワークスペースに追加してから、チームを介してSVNデータを再リンクします->プロジェクトを( 's'を使用して)共有するか、プロジェクトをSVNから最初に切断した後にこの最後のビットを実行します。
プロジェクトフォルダを右クリックします:チーム->ヘッドに更新
これにより、ディレクトリが戻されます。もう一度削除してコミット
私の場合、プロジェクトエクスプローラーにプロジェクトのフォルダーがあり、プロジェクトを再度開く必要がありました
私にとって、このエラーメッセージは、Subclipseの古いインストールと、基礎となるSVNKitおよびJahaHLライブラリが原因でした。 Eclipse以外でTortoiseSVNを使用してプロジェクトディレクトリを管理しており、1.8.xシリーズの(Tortoise)SVNツールへの最近のアップグレードにより、Subclipseの作業コピーが破損しました。
修正するために必要なことは、ヘルプに移動するだけでした&>"新しいソフトウェアのインストール..." [追加...]をクリックします。新しい更新サイトを追加します。 http://subclipse.tigris.org/で最新リリースの最新アップデートサイトを選びました。 servlets / ProjectProcess?pageID = p4wYuA およびそこからアップグレードされたSubclipse。
その後、既存のすべてのプロジェクトが機能し、問題なく接続を解除しようとしていたプロジェクトに再接続できました。
同じ問題があります
新しいプロジェクトがあり、それをSVNに追加しました。その後、すべてのJavaファイルをリファクタリングして名前を変更するまで、すべてが正常に機能します:
move D:/dev/sk_ws/ge-parent/ge-core/src/main/java/com/skillkash/ge/beans/Skbean.java D:/dev/sk_ws/ge-parent/ge-core/src/main/java/com/skillkash/ge/beans/SkBean.java
Path is not a working copy directory
svn: Path 'D:\dev\sk_ws\ge-parent\ge-core\src\main\java\com\skillkash\ge\beans\SkBean.java' is not a directory
SVN URLは次のとおりです。
svn://qnap/share/MD0_DATA/svn/sk/ge-core/trunk
そしてリポジトリのルートは:
svn://qnap/share/MD0_DATA/svn/sk
明らかに、プロジェクトを共有してからサブクリップを使用してファイルを移動しようとしても機能しません。これはバグに違いありません。私はすべてのリファクタリングを日食の外で行い、影響を受けるすべてのファイルを手で編集する必要があります。
プロジェクト全体を一時ディレクトリにチェックアウトしてから、最初のレベルの.svnディレクトリをコピーし、作業コピーの.svnフォルダーをこれに置き換えました。
http:// blog。 itopia.de/directory-svn-taining-working-copy-admin-area-is-missing/275
それは私にとっては嬉しいことです。
pngファイルをプロジェクトに追加しましたが、名前を変更または削除しようとするとこのエラーが発生しました。プロジェクトのクリーニングと更新は何もしませんでした。
svn Team Synchronizingパースペクティブに移動し、ファイルを右クリックして削除しました。これで問題が解決しました。
先ほど、似たような問題がありました。 Subclipse(またはEclipse)が作業コピーの絶対パスを保存しているようです。最もクリーンなソリューションは、リポジトリを新しいパスに再度エクスポートすることです。
コミットされていないコードがある場合は、クリーンエクスポートの上にコピーできます(.svnフォルダーなし)
私もこの問題を抱えており、ワークスペースからプロジェクトを削除しただけです(ファイルをファイルシステムにそのまま残します)。
その後、svnプロジェクトをワークスペースにインポートしました。
インポート-> SVN-> SVNからプロジェクトをチェックアウトします。
既存のリポジトリの場所を使用してファイルをプルしました。
この問題は、Eclipseのエディションを変更し、使用するはずのバージョンよりも前のバージョンであるSubclipseプラグインを使用したときに発生しました。
新しいバージョンをアンインストールし、正しい古いバージョンをインストールしましたが、すべて正常に機能しました。