EGit unstaged files will not go away - eclipse

I have 3 files in the Unstaged Changes box that I cannot make go away. I've reset hard, replace with HEAD version, assumed unchanged: nothing makes these files go away and when I do compares on them with another branch or the HEAD revision, there are no differences. Mystified, so say the least. Also this morning my local Remotes for fetch/pull in Eclipse just disappeared and I had to rebuild them. These events may be related, but I'm not sure. Is there a repair action I can do for EGit? This shouldn't be a line-ending problem like what I've found in my research. I've lost a fair amount of productivity today on this.
I think I've suffered some kind of corruption of the IDE. Can't prove it; it's just a hunch. Here's my relevant info:
Windows 10
Eclipse Java EE IDE for Web Developers.
Version: 2018-09 (4.9.0)
Build id: 20180917-1800
EGit 5.1.0.201809111528-r

Related

How can I prevent TortoiseSVN database locking up?

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...).

Eclipse hangs on reverting resources

I use eclipse Indigo, subclipse 1.10.x and javaNL. Whenever I try to refresh my project in eclipse, it gets stuck at Reverting Resources 0% and Computing Update Requirements 0%. I try to kill eclipse and reopen the project and it still does the same. I do not understand why this happens. It started happening recently. Before it was working fine.
Question: I do not understand why this happens
General Answer: http://www.ihateeclipse.com/
(I may share this opinions and dont think Eclipse should be called a IDE but that wont fix your problem - hence lets proceed with possible workarounds).
Possible Workarounds:
1.) Starting eclipse in clean mode How to run eclipse in clean mode? and what happens if we do so?. (This solved aprox. 80% of my continuously returning 'I messed up my own state' issues I experienced).
2.) If that doesnt help - you would have to stop eclipse, identify the according files (or just any files holding such information) and delete them manually, then restart eclipse. Like I still encounter issues with my "Search Type" (Ctrl+T) and have to delete the files like described here Eclipse type hierarchy not always working (unfortunately I don't know anything about files regarding your current issue - so feel free to downvote my "answer" since its not directly answering your question).
The best things I found about "the full reset" seem to be: http://letsgetdugg.com/2009/04/19/recovering-a-corrupt-eclipse-workspace/ or http://blog.pdark.de/2011/09/02/restoring-a-corrupted-workspace-in-eclipse/ (Note: I haven't verified the described behaviors).
3.) Recreate Workspace - delete any eclipse belongings like the .metadata folder and keep only belongings of your project (e.g. sources, resources etc.). Then create a new eclipse project based on you existing project sources).
4.) If Steps 1-3 failed consider reinstalling Eclipse (include above Step 3 in this process again) or switching to a proper IDE that can at least handle its own state.
5.) I experienced rare cases where in the end such things were triggered by me rather than occurred magically out of nowhere by eclipse - I don't see any possibility on how you could manage that in your case unless you messed around with the eclipse source itself).
Hope this helps - Even thus the SO community is big I experienced way better results asking the eclipse developer community directly when it came to such specific issues (you however oftenly get a link to a open Bug ... that they created because of your question) and ended up "just importing into a new eclipse workspace from existing sources" whenever I experienced such issues lately (It takes me about 5 minutes to checkout our sources, start Eclipse with -clean as default and import existing Maven projects solving any eclipse-only issue - while each of those eclipse-issues can take days to be solved without any further advantage for my daily business)
I don't know if this will help any one but I had the same issue. Some links advised me to delete my metadata, which I did not want to do.
What fixed it for me was:
I have multiple eclipse workspaces, I manually closed my eclipse using the System Monitor/Taskbar as it wouldn't let me close as it was hanging.
I switched workspaces and it seems to run fine. So I switched back to the one that was hanging and the problem seemed to have gone.
This worked for me:
Go to to your workspace instalation, and manually delete the target directory under your maven projects (dont worry , maven will create another one when compiling). This removed my stuck Eclipse state (thread) in "Revert sources", always at 0%.
this helped me:
delete files "*.snap" under org.eclipse.core.resources in
worskpace/.metadata/.plugins/org.eclipse.core.resources/
and share project again (setup SVN settings)
I accidentally checked in target files to SVN. And the target files were huge ans hence it was stuck on reverting resources. Once I deleted those target files from SVN this issue never happened.But JBA's answer is pretty comprehensive so I will mark that as a right answer.
I have this same issue, and I just quickly cancel the "Rerverting Resources" task while it's in "waiting" mode when restart Eclipse.
This should work to 100% and helped in my case (no other tried solution worked):
Go to "Eclipse > Help > About Eclipse IDE > Installation Details
Uninstall the following packages "Subclipse", "Subclipse Integration for Mylyn", "Subversion 1.14 JavaHL", "Subversion Revision Graph", "SVN Client Adapter".
pluginsToUninstall
Go to the marketplace and install "subclipse" again.
Rightclick on your project > Team > Refresh/Cleanup
You are welcome. :)

Developing in eclipse without using any git eclipse plugin?

I've been using SVN and Eclipse for development for a while, and love the strong integration between the two. However I'm now switching over to git, and understand that while the git Eclipse plugins like EGit have gotten better, they're still not as good as SVN plugins for Eclipse. (For example, there's still no submodule support, and I plan to use submodules extensively.)
I'm wondering, are there any of you who use Eclipse for development on a git project but don't use the Eclipse plugin? Meaning, you either use another git GUI client (I'm on Linux) or do everything from the command line. If so, how does this work for you?
Is it a big pain not to be able to see directly in Eclipse which files are not synchronized with the repository, etc, or is that not such a big deal? Or can I still use EGit just to see which files have changed, but make all commits and do all operations from the command line or another GUI client? If so, could anyone who's doing that describe what such a workflow might look like.
Is there any risk or problems involved with accessing one repository from multiple clients, such as command line, EGit, and multiple git GUI clients - like could it cause repository corruption because they could all change metadata at the same time? Or is it perfectly safe?
With SVN everything was simple - I never needed the command line or another GUI client for anything. Everything was possible within Eclipse. But now I'm concerned about what to expect because I really don't know how this will change my development style or if it's doable. Certainly with git being such a popular VCS and Eclipse being such a popular IDE, there are many who use both together and who can describe for me how they use it.
EGit will play fairly well with the command line git tool. I use both on linux. It's still worth installing EGit, I think, and then at least you see the status of your projects.
Sometimes you have to use F5-Refresh to refresh EGit's view of your repo, but EGit already works at refreshing the workspace with local file changes, so it doesn't come up that often.
The only other suggestion that I have is that you wouldn't want multiple workspaces to point to the same git repo. That can cause confusion.
I can't speak specifically for git, but I used to do something very similar with SVN, and I can't see any issues with doing this. Additionally, at least with SVN and Subclipse, Subclipse worked with the SVN working copy just as any other SVN client would. There are several operations that I still use the svn command-line tool for against the same projects I'm working on Eclipse. This includes things like "svn status", as well as doing batch updates of SVN properties across files (something Subclipse doesn't currently support). Other than needing to use F5 in Eclipse to perform an occasional refresh, I've never had any issues with this.
I've done very similar things with several other source control systems, and never had any issues. Especially if you just use an external client and don't worry about source control integration into Eclipse for git, I can't see that you'd have any problems, as Eclipse won't attempt to share any concern with this. I would also reommend trying EGit, as I'm guessing it will work very similar to Subclipse and not cause any significant issues. (I hope to do this soon myself.)
In terms of the workflow, in many cases - at least for an experienced developer, this should work better in some cases. In Eclipse, I often find myself switching between the Package Explorer and Navigator views to see all the files that Eclipse hides or translates by default in the Package Explorer view. Switching between Eclipse and another client really doesn't work any differently.

How can I refactor in Helios with Subclipse without problems committing changes?

I am running Eclipse Helio with Subclipse on Windows XP.
When I do simple refactoring in Java that results in folders being deleted, commit fails. I can get around this one folder at a time by "update to head" and then "Mark Resolved" but this is very tedious.
In more complex refactors, things seem to get tangled where even that doesn't work.
I am not doing anything weird like going outside of eclipse to move files around, etc.
Help! This makes SVN almost unusable.
I don't know what is exactly the use case, but I haven't seen such behavior. try to synchronize before you do the actual commit.
Team -> synchronize...

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?
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.