Subclipse: Updating Change Sets for SVNStatusSubscriber (UPDATED - clock sync issue)_问答_开发者

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?

Subclipse: Updating Change Sets for SVNStatusSubscriber (UPDATED - clock sync issue)

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.