Subclipse se plaint "le chemin n'est pas une copie de travail" après le déplacement d'un espace de travail
J'ai récemment déplacé mon répertoire d'espace de travail Eclipse et maintenant, Subclipse se plaint à chaque fois que j'ouvre un fichier, en effectuant un vidage sur la console, par exemple:
Le chemin n'est pas un répertoire de travail.
svn: '[chemin du répertoire d'origine (avant le déplacement)]' n'est pas une copie de travail
Aucun fichier ou répertoire de ce nom
Cela se produit également lorsque j'essaie explicitement d'afficher l'historique d'un fichier. Cela persiste lors des nettoyages SVN, lors de la fermeture et de la réouverture d'Eclipse, etc.
Les mises à jour, les archivages, les caisses, etc., semblent fonctionner correctement. Tortoise ne se plaint pas du tout. Il est donc clair que ce ne sont pas les métadonnées SVN qui sont gachées, mais des métadonnées spécifiques à Subclipse. Quelqu'un peut-il me dire comment supprimer ces métadonnées brisées?
Edité pour ajouter: "Team> Disconnect" suivi de "Team> Share" ne résout pas le problème.
Édité à nouveau pour ajouter: J'ai parcouru tout le répertoire .metadata et l'un des répertoires du projet pour un élément unique de l'ancien chemin et ne le trouve nulle part sauf dans .metadata/.log (le message d'erreur lui-même) et quelques-uns anciens avertissements Findbugs. Très agréable.
J'avais le même message d'erreur en utilisant subclipse avec javahl sur un projet hors du répertoire de l'espace de travail. Passer à svnKit a résolu mon problème.
Vous devez supprimer les fichiers .syncinfo. Cela se fait facilement (dans la plupart des cas) en fermant et en ouvrant Eclipse, mais vous pouvez également le faire manuellement, comme dans les cas suivants:
Pour supprimer le cache, fermez Eclipse. Le cache est stocké dans:
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects/PROJECTNAME/.syncinfoDonc, vous pouvez simplement trouver et supprimer tous les fichiers nommés
.syncinfodans[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects
Extrait de cet article: http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=868799
Je viens de faire un "Team -> Cleanup" et cette erreur exacte a disparu! J'ai aussi eu cette erreur parce que j'ai changé de machine et que le chemin n'était pas le même.
Utilisation d’Eclipse 3.6 et du plugin Subversion 1.6.
Mise à jour en 2016: Fonctionne toujours parfaitement avec Eclipse 4.5.2 et Subclipse 1.10.
Modifié pour ajouter: Non, a parlé trop tôt. Cela ne le répare pas. Certains fichiers ne semblent tout simplement pas présenter le problème.
Ce qui suit semble résoudre le problème:
- Équipe> Déconnecter.
- Quittez Eclipse.
- Soufflez
.metadata/.plugins/org.tigris.Subversion.subclipse.*. - Redémarrez Eclipse.
- Équipe> Partager.
Vous ne savez pas comment l'ancien chemin était réellement stocké dans les préférences du plug-in, mais il devait être là quelque part. C'est un peu pathétique de Subclipse de stocker des chemins absolus, mais apparemment ça l'est.
Il y a un bogue enregistré sur ce , ou du moins sur le même message d'erreur. Pas de contexte. Cinquante cents dit que le projet est rejeté.
J'ai eu l'erreur lorsque j'ai essayé de renommer une classe en modifiant le cas de DAO à Dao dans Eclipse.
Je devais le renommer avec quelque chose comme Dao2 et ensuite pouvoir le renommer en Dao.
Je suis sûr qu'il existe de nombreuses causes avec différentes solutions, mais j'ai trouvé celle qui fonctionnait pour moi sur le blog de Dan Wilson . Supprimez simplement les dossiers incriminés de l'espace de travail (en les enregistrant probablement s'ils ont un nouveau contenu), mettez à jour (laissant Subversion recréer les dossiers), puis déplacez le contenu dans les nouveaux dossiers de votre espace de travail.
Ce qui a fonctionné pour moi: Faites un "refactor - renommer" sur le projet => puis refaites-le pour le renommer au nom original.
Dans mon cas, j'avais les dossiers des projets dans l'explorateur de projets et je devais rouvrir le projet
extraire l'intégralité du projet dans un répertoire temporaire, puis j'ai copié le répertoire .svn de premier niveau et remplacé mon dossier .svn de travail.
http://blog.itopia.de/directory-svn-containing-working-copy-admin-area-is-missing/275
Ça me convient.
J'avais ajouté un fichier png à mon projet, mais j'ai eu cette erreur en essayant de le renommer ou de le supprimer. Nettoyer et rafraîchir le projet n'a rien fait.
Je suis entré dans la perspective de synchronisation de l'équipe svn, j'ai cliqué avec le bouton droit sur le fichier et je l'ai supprimé. Cela a résolu mon problème.
Cliquez avec le bouton droit sur le dossier du projet: Équipe -> Mettre à jour en tête
Cela ramènera le répertoire. Supprimez-le à nouveau et validez
Pour moi, ce message d'erreur était dû à une installation obsolète de Subclipse et aux bibliothèques SVNKit et JahaHL sous-jacentes. J'utilisais TortoiseSVN en dehors d'Eclipse pour gérer mes répertoires de projet et ma récente mise à niveau vers la série 1.8.x d'outils SVN (Tortoise) a brisé mes copies de travail pour Subclipse.
Tout ce que je devais faire pour réparer était d'aller dans Aide -> "Installer un nouveau logiciel ..." et cliquez sur "Ajouter ..." pour ajouter un nouveau site de mise à jour. J'ai choisi le dernier site de mise à jour pour la dernière version sur http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA et j'ai mis à niveau Subclipse à partir de là.
Ensuite, tous mes projets existants ont juste fonctionné et je pouvais me reconnecter à celui dont j'avais déjà essayé de me déconnecter sans problèmes.
J'ai le même problème
J'ai eu un nouveau projet, l'a ajouté à SVN. Puis tout fonctionne normalement, jusqu'à ce que j'essaye de renommer n'importe quel fichier Java, je reçois:
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
Maintenant, l'URL du SVN est:
svn://qnap/share/MD0_DATA/svn/sk/ge-core/trunk
et la racine du référentiel est:
svn://qnap/share/MD0_DATA/svn/sk
Évidemment, le simple partage du projet puis le déplacement d'un fichier à l'aide d'un sous-tuyau ne fonctionnent pas - il doit s'agir d'un bogue Je dois effectuer tout mon refactoring en dehors d'Eclipse et éditer à la main tous les fichiers concernés.
Difficile à dire sans plus d'informations.
Avez-vous déplacé tout l’espace de travail ou juste le contenu?
Vous pouvez également essayer de créer un nouvel espace de travail à partir de zéro et extraire à nouveau le projet dans son intégralité.
Vous pouvez également essayer de supprimer le répertoire .metadata et relier à nouveau le projet en utilisant Fichier -> importer -> projet existant dans l’espace de travail, puis de relier les données SVN via Team -> Share projects (avec un 's'), ou peut-être simplement le faire. ce dernier bit après la première déconnexion du projet de SVN.