Subclipse se plaint. & # 8220; Path n’est pas une copie de travail & # 8221; après le déplacement de l'espace de travail

https://stackoverflow.com/questions/1425891

07-07-2019
|

Question

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 et effectue un vidage sur la console, comme 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 type

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.

La mise à jour, l'enregistrement, la sortie, etc., semblent bien fonctionner. 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?

Modifié pour ajouter: " Équipe > Déconnecter " suivi de " équipe > Partager " ne résout pas le problème.

Modifié à nouveau pour ajouter: j'ai parcouru tout le répertoire .metadata et l'un des répertoires de projet pour un élément unique de l'ancien chemin, mais je ne peux pas. trouvez-le n'importe où, sauf dans .metadata / .log (le message d'erreur lui-même) et dans certains anciens avertissements de Findbugs. Très sympa.


	
		
					
				
					
						

	
		
			
				




				




			
			
				Était-ce utile?				 
					 
						 
						
					
							
				
				
					 
						 
						
					
					
				
				
			
			
				
					
				
			
		
	


					
					
											
				
				
	
		
			 La solution 		
		
			 J'avais le même message d'erreur lors de l'utilisation de subclipse avec javahl sur un projet situé en dehors du répertoire de l'espace de travail. Passer à svnKit a résolu mon problème.



	
					
			
			


	
			


	
			
						 Autres conseils
			
			
	
		
	
	
			 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 suit: 


   Pour supprimer le cache, fermez Eclipse. Le cache est stocké dans: 

[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects/PROJECTNAME/.syncinfo

  
   Vous pouvez donc simplement rechercher et supprimer tous les fichiers nommés  .syncinfo  dans 

[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects



 Cités dans cet article:  http://subclipse.tigris.org /ds/viewMessage.do?dsForumId=1047&dsMessageId=868799  
	


	
		
	
	
			 Je viens de faire une " équipe - > Nettoyage " et cette erreur exacte est partie! J'ai aussi eu cette erreur parce que je changeais de machine et que le chemin n'était pas le même. 

 Utilisation d'Eclipse 3.6 et du plug-in 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 exactement comment l'ancien chemin a été stocké dans les préférences du plug-in, mais il doit y avoir été quelque part. C'est un peu pathétique de Subclipse de stocker des chemins absolus, mais apparemment, c'est le cas. 

 Il y a  un bogue déposé à ce sujet , ou du moins sur le même message d'erreur. Pas de contexte. Cinquante cents dit que le projet est rejeté. 
	


	
		
	
	
			 Je suis sûr qu'il existe de nombreuses causes pour différentes solutions, mais j'ai trouvé celle qui fonctionnait pour moi à l'adresse  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 (en laissant Subversion recréer les dossiers), puis déplacez le contenu dans les nouveaux dossiers de votre espace de travail. 
	


	
		
	
	
			 J'ai eu l'erreur lorsque j'ai essayé de renommer une classe en modifiant le casse de  DAO  en  Dao  dans Eclipse. 

 Je devais le renommer, par exemple  Dao2 , puis le renommer  Dao . 
	


	
		
	
	
			 Ce qui a fonctionné pour moi:
Effectuer un "refactor - renommer" sur le projet = > faites-le ensuite pour le renommer. 
	


	
		
	
	
			 Difficile à dire sans plus d'informations. 

 Avez-vous déplacé l'intégralité de l'espace de travail ou uniquement 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 de relier à nouveau le projet en utilisant Fichier - > importer - > projet existant dans l’espace de travail, puis reliez les données SVN via Team - > Partager des projets (avec un 's'), ou peut-être simplement faire ce dernier bit après avoir d'abord déconnecté le projet de SVN. 
	


	
		
	
	
			 Cliquez avec le bouton droit de la souris sur le dossier du projet: Team - > Mise à jour de la tête 

 Ceci ramènera le répertoire. Supprimez-le à nouveau et validez 
	


	
		
	
	
			 Dans mon cas, j'avais les dossiers des projets dans l'explorateur de projets et je devais rouvrir le projet 
	


	
		
	
	
			 Pour moi, ce message d'erreur a été causé par une installation obsolète de Subclipse et des bibliothèques SVNKit et JahaHL sous-jacentes. J'utilisais TortoiseSVN en dehors d'Eclipse pour gérer les répertoires de mon 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ésoudre ce problème était d'aller dans Aide - > "Installer un nouveau logiciel ...". et cliquez sur "Ajouter ...". ajouter un nouveau site de mise à jour. J'ai choisi le dernier site de mise à jour de la dernière version sur  http://subclipse.tigris.org/. servlets / ProjectProcess? pageID = p4wYuA  et a mis à niveau Subclipse à partir de là. 

 Ensuite, tous mes projets existants fonctionnaient 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, je l'ai ajouté à SVN. Ensuite, 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, partager le projet puis essayer de déplacer un fichier à l’aide de sub-clip ne fonctionne 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. 
	


	
		
	
	
			 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 svn Team Synchronizing, j'ai cliqué avec le bouton droit sur le fichier et je l'ai supprimé. Cela a résolu mon problème. 
	


	
		
	
	
			 Il y a quelque temps, j'ai eu un problème similaire. Il semble que Subclipse (ou Eclipse) stocke le chemin absolu de vos copies de travail. La solution la plus propre consiste à réexporter votre référentiel vers le nouveau chemin. 

 Si vous avez un code non engagé, vous pouvez le copier par-dessus l'exportation propre (sans le dossier .svn) 
	


	
		
	
	
			 Moi aussi j'avais ce problème et j'ai simplement supprimé le projet de l'espace de travail (en laissant les fichiers du système de fichiers intacts). 

 J'ai ensuite importé un projet svn dans l'espace de travail. 

  Importer - > SVN- > Projet Checkout de SVN.  

 J'ai utilisé mon emplacement de référentiel existant pour extraire les fichiers. 

 Ce problème est dû au fait que j'ai modifié les éditions Eclipse et utilisé un plug-in Subclipse, une version antérieure à celle que j'aurais dû utiliser. 

 J'ai désinstallé la nouvelle version et installé l'ancienne version correcte, et tout a bien fonctionné. 
	

			
		
			


	
		
			Licencié sous: CC-BY-SA avec attribution
			Non affilié à StackOverflow