I'm trying to create a new phonegap project in a new repository. When ever I add a new folder or file I get the following error. This is a completely fresh copy of eclipse in a new workspace and fresh install of subclipse.
Errors occurred while updating the change sets for SVNStatusSubscriber
org.apache.subversion.javahl.ClientException: svn: E155007: 'Workspace/PhoneGap/www/js' is not a working copy
org.apache.subversion.javahl.ClientException: svn: E155007: 'Workspace/PhoneGap/www/js' is not a working copy
org.apache.subversion.javahl.ClientException: svn: E155007: 'Workspace/PhoneGap/www/js' is not a working copy
I've no idea what is causing the issue, everything I've found through google has said a fresh install or fresh workspace should fix the issue. I've also selected SVNKit to be the SVN Client as I've had issues with JavaHL before and the fix was to switch to SVNKit.
Eclipse Installation and Versions:
For whatever reason, it looks like the SVNKit 1.7.x API (which is still in beta) does not think that folder is a working copy. I cannot really say if it is right/wrong or why, but that is the error the API is throwing.
They have released a beta2 recently. You could get that update from their update site.
If you have SVN 1.7.x command line you could use it to examine the WC and that folder using the svn status command.
I have the same issue, but get the error in my /bin folder. Obviously my /bin folder is not svn-added to my remote svn server... because we don't want to keep binaries in addition to source in svn.
After trying to clean-build my projects, I got the same error. I assumed the svn plugin was somehow mucking stuff up, and disabled them. (in osgi console, stop all the id's related to svn).
I then got hte following stack trace:
java.lang.NullPointerException
at org.tigris.subversion.subclipse.core.SVNClientManager.getAdapter(SVNClientManager.java:127)
at org.tigris.subversion.subclipse.core.SVNClientManager.getSVNClient(SVNClientManager.java:94)
at org.tigris.subversion.subclipse.core.SVNProviderPlugin.getSVNClient(SVNProviderPlugin.java:462)
at org.tigris.subversion.subclipse.core.repo.SVNRepositoryLocation.getSVNClient(SVNRepositoryLocation.java:274)
at org.tigris.subversion.subclipse.core.resources.SVNMoveDeleteHook.deleteResource(SVNMoveDeleteHook.java:47)
at org.tigris.subversion.subclipse.core.resources.SVNMoveDeleteHook.deleteFolder(SVNMoveDeleteHook.java:110)
at org.eclipse.team.internal.core.MoveDeleteManager.deleteFolder(MoveDeleteManager.java:62)
at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1940)
at org.eclipse.core.internal.resources.Resource.delete(Resource.java:780)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.cleanOutputFolders(BatchImageBuilder.java:114)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:46)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:173)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
Now this stack trace is due to me stopping the plugins, but, it does give a clue what was happening before I disabled the plugins.
It seems that svnkit is now treating the deletion of my bin folder (which gets deleted as part of a clean build process) as an error, since my bin folder has no .svn subfolder (aka is not a working copy).
So this means their code somehow assumes that all folders should be a working copy, and if they're not it's an error. Their code seems to ignore hte possibility that I might have a folder in my local tree that I do not want to commit remotely.
balls.
I had the same annoying problem with bin complaining. I checked in workspace/preferences/Team/svn
There in client, I had option of SVNKit or JavaHL. I changed mine from javahl to SVNkit and restarted. The problem seems to have gone :-)
I also deleted the bin folders for the complaining projects and did the above. Maybe combination should work for other cases. I presume it was the JavaHL that was the problem.
I also got this error after upgrading my Eclipse.
svn: E155007 '/somepath' is not a working copy
The reason was that I was still running SVN 1.6 on my MacOSX machine (run svn --version on command line) but downloaded Subclipse 1.10 which seems to require SVN 1.8
I had to install Subclipse 1.6 in order to remove this strange message.
Side note: After re-installing subclipse, I also had to remove all bundles in the project and import them again, so that the SVN folders got recognized
Related
I have a Windows 7 PC with the latest TortoiseSVN version (1.11.0 x64). Almost every time I want to commit changes to the server, I get the following error:
Commit failed (details follow):
Failed to load properties: sqlite[S5]: database is locked
Error unlocking locked dirs (details follow): sqlite[S5]: database is locked
Another process is blocking the working copy database, or the underlying filesystem does
not support file locking; if the working copy is on a network filesystem, make sure file
locking has been enabled on the file server.
It's easy to fix - I just go to the project root folder, do an SVN cleanup, and then the commit works fine. However, if I want to commit again a few minutes after that, it will most likely fail again and force me to do another cleanup. It gets really annoying.
Is there any way I can prevent these locks from happening? Any settings I can change on TortoiseSVN, or something?
A few more details:
Both my SVN projects and TortoiseSVN itself are placed in my local HDD (no network filesystem), and their folders are excluded from the antivirus software.
The working copy folder is not network shared (nor locally, I'm the only user on that PC).
I don't have Dropbox, Google Drive or any other cloud software sync'ing the folder, either.
It's specific to TortoiseSVN, I never get this error when I commit my changes from Eclipse.
I really don't think it's a TortoiseSVN bug though, I recently updated from version 1.9.6 to 1.11.0 and both had the same issue, if this really was a bug it surely would have been fixed... right? :)
I'm the only developer currently working with the projects (it's not an issue of my local database being out of date, or existing conflicts).
I also think the lock is caused by eclipse plugin. Here some more details about my setup and how I got rid of the problem:
Tortoise: TortoiseSVN 1.12.2, Build 28653 - 64 Bit , 2019/08/04 13:03:09
Subversion: Subversion 1.12.2, -release
Eclipse: Spring Tool Suite Version: 3.9.6.RELEASE (eclipse Eclipse 2018-09 (4.9.0))
SVN-Plugins in eclipse:
Subversive Revision Graph (Optional) 4.0.0.I20160226-1700
Subversive SVN Connectors 6.0.4.I20161211-1700
Subversive SVN Team Provider 4.0.5.I20170425-1700
SVNKit 1.8.14 Implementation (Optional) 6.0.4.I20161211-1700
Subversive SVN Integration for the M2E Project (Optional) 4.0.0.I20160226-1700
After de-installing the last (optional) plugin ("Subversive SVN Integration for the M2E Project") the lock on explorer's tortoise didn't occure anymore.
So I am happy because all functionality I use within eclipse still works, and tortoise in explorer works also. Usually I only use the "team/show annotation" context menu in eclipse, all other SVN stuff I do in explorer through tortoise.
Edit: the problem wasn't actually caused by Eclipse itself. It was either the Subversive plugin, or the SVNKit connector. I've switched to Subclipse and JavaHL, and the problem has completely disappeared. I haven't tried with Subclipse+SVNKit, nor Subversive+JavaHL, I guess one of these combinations will solve the problem too, and the other won't.
It seems that the problem is caused by Eclipse. We usually structure our SVN projects like this:
/trunk
/docs
/etc
/scripts
/source
/pom.xml
/src/main/...
I checkout the whole trunk (or some branch), and then import the source projects into Eclipse.
To manage code changes, I use the SVN sync view in Eclipse, which is more user-friendly (just my opinion) than TortoiseSVN. For changes outside the /source folder I have to use TortoiseSVN, since the files aren't in Eclipse.
The problem is that apparently, Eclipse has some background process which "updates the SVN cache" every few minutes, even if you didn't change anything on that project, just by having it open in the workspace. And it messes up TortoiseSVN, hence the errors unless I perform a cleanup.
There is an option in Eclipse, under Team > SVN > Performance, which allows to disable the SVN status cache... but the last time I tried, it didn't prevent the issue, it only made Eclipse SVN sync slower.
I guess my only choices here are to use different checkout folders for Eclipse and TortoiseSVN (ugh...), or to disable SVN in Eclipse and use always TortoiseSVN (ugh...).
For some days now Ecplise (Oxygen 4.7.1a) shows me question marker icons at all folders and files in the project explorer.
I figured out that this is caused by a broken SVN synchronization. Eclipse error log shows The SVN synchronization information for 'Project' has become corrupt or does not exist.
I use Subclipse (latest version) from Eclipse market place.
I tried:
removing and reinstalling Subclipse
removing workspace and check out SVN repo again
Still the same problem.
The curious thing is that SVN connection is ok. I can use Tortoise SVN in Windows explorer and SVN command line, but Subclipse in Eclipse does not work.
Any solutions to this?
I had the same. I tried the one thing in the link recommended by howlger, namely:
"Close Eclipse. Open your workspace folder and then navigate to:
.metadata\.plugins\org.eclipse.core.resources\.projects
There will be a folder for each project, each will have a file named .syncinfo
in it. Delete all of these files and restart Eclipse."
It did not help. But then I tried "Add to Version Control". It complained that the project is already under Version Control, but the question mark is gone and everything seems to work OK now.
I have installed a virtual box with Windows 10, Eclipse Mars, Subversive Plugin, SVNKit 1.8.11 and tried to set up some repositories in a configuration I already did successfully in several other environments. The SVN server is a Debian 7 system with Subversion 1.6.17. The following problem occurs only since I set up the above mentioned system:
Check-out: e. g. SVN-Repositories -> expand Repository X -> right-click on trunk -> check-out -> Error occurs: "Checkout operation for 'svn://host/X/trunk' failed. svn: E200030: There are unfinished transactions detected in 'C:\PathToWorkspace\X'"
After this the Subversive plugin stops working, apparently.
Export: same result as check-out
Further investigation got me to a specific file in the repository, which fails loading with "invalid handle" error. It is not in a "strange" path (not too long, no spaces or special characters) and the file itself contains no suspicious characters, just Unix line breaks. Permissions and space on disk are OK. Other respositories with the same properties DO work as expected.
I found posts with similar problems, but none of them applied to mine, apparently. They told me to wipe my workspace directory (which I did), but I just lost all of my settings without solving the problem. After this, I investigated the program directory of Eclipse, whicht didn't bring any more success.
Additionally, the ".svn\wc.db" file is still locked after the failure. Deleting the repository is therefore not possible until closing Eclipse. The directory is not listed in any project list/tree in eclipse like the package explorer, but the directory exists on the disk.
The same repository X still works in every of the other configurations I have. How can I reset these "transactions" in order to repair this? I really would like to avoid completely reinstalling Eclipse or even Windows.
EDIT
I istalled TortoiseSVN 1.16.16.21511 (x64), which perfectly fits to the SVN service version. Same problem.
First, try:
Right-click the project -> Team -> Cleanup.
If that didn't help:
Restart Eclipse -> Team -> Cleanup
I got the same error in my case but in different situation, I was working on the shared folder using both Eclipse and Tortoise SVN, and Eclipse was not able to clean up or do any commit, so I tried to close Eclipse and do clean up from outside using tortoise. it worked.
I finally got it: creating the files "con.cpp" and "con.h" from the project had apparently been rejected by Windows. As far as I remember, "con" is kind of a reserved command or sub command in Windows. Renaming it to something else right in the repository solved the problem.
When you are performing any team operations in eclipse ( such as
commit, update, replace ) and if you cancel the operation in between.
The files involved in the operation are locked.
This is one of the possibilities for the error to appear.
To resolve this in Eclipse.
Right Click on the project -> Team -> Cleanup
If the above process doesn't work
Restart eclipse -> Right Click on the project -> Team -> Cleanup
If this didn't resolve the issue.
Remove these locks explicitly.
Ubuntu
Install svn if you haven't installed.
sudo apt-get install subversion
Then clean the project folder.
svn cleanup /path/to/working-copy
Windows
Get Tortise SVN from this link.
After installing, Right-click on the project folder which is linked to SVN.
There will be an option do SVN cleanup. Click on it. It takes some time to clean up.
Then you are good to go.
This solution worked for me.
i had an error also on the command 'cleanup' on a project, and restarting the eclipse didn't solve.
i had to disconnect the project from svn and re-connect later
I had the same issue, unfortunately, the issue with the device storage running out of memory.
Free up the memory and able to proceed further from the mentioned issue
I have Eclipse Luna with Subversive, and I had two problems to syncronize with the Repository in a Server, E170001 and E20030 (sometines one and sometimes both). My solution was:
1.- In Eclipse: go to to "Window" - "Preferences".
2.- Go to "General" - "Network Connections".
Down, at Proxy Bypass, add de IP of the server where you has the Repository of SVN.
I see this when digging into the error logs of Eclipse - I keep getting an error:
An internal error occurred during:
"Updating Change Sets for
SVNStatusSubscriber"
It happens a few times when trying to update or commit, and eventually hoses my local copy of SVN, and I'm forced to rebuild it.
Has anyone every encountered either of these or have any thoughts on fixing? It's a huge annoyance to have to rebuild SVN each time. I'm using Subclipse with Helios. Also I'm connected via FUSE/SSHfs to the project on a VM.
Did samba fix it? Have you tried using different client implementations?
Okay, so this is still not 100% certain, but it would appear that what's happened is that the date goes out of sync on the VM on occassion. During svn updates or commits, this causes inconsistent synchronization data and the client in Eclipse, confused, ends up throwing errors.
Because the errors cause an abort of the update or commit process, this leaves the repository in a very unstable state, my guess is that it tries to retrieve a name of a file but gets back null, and ends up writing this back to the .svn/entries somehow.
As I said I can't confirm that this is the only thing causing the problems, but it makes sense as after my clock went out of sync, pretty much all of svn was broken on the next svn up call.
Hey so I had a similar issue, and this seems to have fixed the problem (keeping my fingures crossed that it stays fixed.)
right click on the project to open the options then set Team->Refresh/Cleanup. I am using a local repository so not sure if this will help you.
This is rather old however it has been viewed thousands of times which makes me feel that it's still a relevant issue. I arrived on this page because I had the same question.
The steps to fix the issue are
Ensure that you have an SVN client actually installed. (ex. if you are using Catalina make sure Catalina is actually installed)
If you are using extra tools on top of your SVN client such as TortoiseSVN ensure that it's installed. Most tools have co-dependencies to the official SVN release. (ex. TortoiseSVN versions closely match SVN versions)
Check if SubEclipse is installed (Help > Eclipse Marketplace > Type: subeclipse). When you update your SVN client SubEclipse needs to catch up. If you see the Install button available click it, most likely it will update SubEclipse to look at the right SVN client
If you get a Working-Copy error go to the actual folders in question through your OS and right click on the folders and choose "SVN Update"
If you are still having an issue in Eclipse choose your project(s) and right click > Team > Refresh/Cleanup. Then right click > Team > Synchronize with Repository
Hopefully one of the 5 steps will resolve your issue. In my case I had to do all 5.
As a solution to this problem, uninstall the svn client from eclipse. Go to Help -> about -> installation details -> select all subclipse plugins and click uninstall. After this install Subclipse from using subclipse update site. Don't forget to restart eclipse / STS whenever asked to do so.
Doing so solved my this problem. Hope this helps in your case as well.
I had the same problem, after creating some new classes. I've fixed it after synchronizing with repository of the parent package. the svn error "Updating Change Sets for SVNStatusSubscriber" disappered.
Changing the SVN client from eclipse with restart or start eclipse with "-clean" option didn't work for me.
My observation is that commonly the SVN commit fails, when there is a collision in XML files. SVN is not correctly reporting and updating XMLs. I had to delete (move the res folder to a temporary folder outside project) the entire folder, commit, restore the folder and commit again. I have not tried, but I think automatic build for Eclipse should be disabled before taking update. However you can get the version updates from team-->history, from there you can extract the updates to a folder, to compare the updates are done properly.
I recently moved my Eclipse workspace directory and now Subclipse complains every time I open a file, dumping to the console something like:
Path is not a working copy directory
svn: '[original (pre-move) directory path]' is not a working copy
No such file or directory
This also happens when I explicitly try to view the history of a file. This persists across SVN cleanups, closing and re-opening Eclipse, etc.
Update, checkin, checkout and so on all seem to work fine, and Tortoise doesn't complain at all, so clearly it's not the SVN metadata that's screwed up, it's some Subclipse-specific metadata. Can anyone tell me how to blow this broken metadata away?
Edited to add: "Team > Disconnect" followed by "Team > Share" doesn't solve the problem.
Edited again to add: I've grepped through the whole .metadata directory and one of the project directories for a unique element of the old path and can't find it anywhere except in .metadata/.log (the error message itself) and some old Findbugs warnings. Very nice.
You need to delete the .syncinfo files. This is easily done (in most cases) by closing and opening Eclipse, however you can also do so manually as in the following:
To delete the cache, close Eclipse. The cache is stored in:
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects/PROJECTNAME/.syncinfo
So you can just find and delete all files named .syncinfo in
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects
Quoted from this article: http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=868799
I just did a "Team -> Cleanup" and this exact error went away! I also got this error because I moved between machines and the path wasn't the same.
Using Eclipse 3.6 and the Subversion 1.6 plugin.
Update in 2016: Still works perfectly with Eclipse 4.5.2 and Subclipse 1.10.
Edited to add: Nope, spoke too soon. This doesn't fix it. Some files just seem not to exhibit the problem.
The following seems to solve the problem:
Team > Disconnect.
Quit Eclipse.
Blow away .metadata/.plugins/org.tigris.subversion.subclipse.*.
Restart Eclipse.
Team > Share.
Not sure how the old path was actually being stored in the plugin prefs, but it must have been in there somehwere. It's kind of pathetic of Subclipse to store absolute paths, but apparently it is.
There's a bug filed on this, or at least on the same error message. No context. Fifty cents says it gets rejected.
I'm sure there are many causes with different solutions, but I found the one that worked for me at Dan Wilson's blog. Simply remove the offending folders from the workspace (probably saving them if they have new content), update (letting Subversion recreate the folders), then move the contents back into the fresh folders in your workspace.
I got the error when I tried to rename a class by changing the case from DAO to Dao in Eclipse.
I had to rename it to something like Dao2 and then was able to rename it to Dao.
What worked for me:
Do a "refactor - rename" on the project => after that do it again to rename it back to the original name.
I was having the same error message using subclipse with javahl on a project that is out of the workspace directory. Changing to svnKit has resolved my problem.
Hard to say without further information.
Did you move the whole workspace or just the content?
Also, you can try creating new workspace from scratch and check out the whole project again.
Alternatively, you may try deleting the .metadata directory and relink the project again using File -> import -> existing project into workspace and then relink the SVN data through Team -> Share projects (with an 's'), or maybe just do this last bit after first disconnecting the project from SVN.
Right click the project folder : Team -> Update to Head
This will bring back the directory. Delete it again and Commit
In my case I had the folders of the projects in the Project Explorer and just had to reopen the project
For me, this error message was caused by an out-of-date installation of Subclipse, and the underlying SVNKit and JahaHL libraries. I have been using TortoiseSVN outside of Eclipse to manage my project directories, and my recent upgrade to the 1.8.x series of (Tortoise)SVN tools broke my working copies for Subclipse.
All I had to do to fix, was go to Help->"Install New Software..." and click "Add..." to add a new update site. I picked the latest update site for the latest release on http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA and upgraded Subclipse from there.
Then all my existing projects just worked, and I could reconnect to the one I had already tried disconnecting from without problems.
I have the same problem
I had a new project, added it to SVN. Then everything works as normal, until I try and refactor-rename any java file, I get:
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
Now the SVN URL is:
svn://qnap/share/MD0_DATA/svn/sk/ge-core/trunk
and the repository root is:
svn://qnap/share/MD0_DATA/svn/sk
Obviously just sharing the project then trying to move a file using subclipe does not work - it must be a bug. I have to do all my refactoring outside eclipse, and hand edit all the files which are affected.
checkout the whole project to a temp dir, then I copied the first level .svn directory and replaced my working copy .svn folder with this.
http://blog.itopia.de/directory-svn-containing-working-copy-admin-area-is-missing/275
It woks for me.
I had added a png file to my project, but I got this error trying to rename or delete it. Cleaning and refreshing the project didn't do anything.
I went into the svn Team Synchronizing perspective, right clicked on the file and deleted it. That solved my problem.
Right click on the project and select Teams -> Switch to another Branch/Tag/Revision.
Select the appropriate Branch/Tag/Revision that the project should be tied to and click OK.
Give Eclipse some time to process the changes.
Restart Eclipse for the changes to take affect.
I just got this error when I was trying to update some .java files. The problem was I was trying to update the files but the folder that contains that files didn't exist in the path so when I sync and update the folder it works at the first try.
So, dont try to sync files, try to sync the folder.
Sometime ago I had a similar issue. Seems that Subclipse (or Eclipse) stores the absolute path of your working copies. The cleanest solution is to export again your repository to the new path.
If you have non-committed code, then you can copy it on top of the clean export (without the .svn folder)
I too had this issue and I simply deleted the project from the workspace (leaving the files on the files system in tact).
I then imported an svn project into the workspace.
Import->SVN->Checkout Project From SVN.
I used my existing repository location to pull the files in.
This issue was caused when I changed Eclipse editions and used a Subclipse plug-in that was a version ahead of what I should have used.
I uninstalled the newer version and installed the correct older version and all worked well.