I have had this problems for a couple of times but usually could solve it by an update. However, this fix does not work for me anymore.
Actually, two problems here:
The minor one: I have osX 10.8.3 and Eclipse Juno (M20130204-1200) installed. Since a good amount of time, it takes eclipse ~ 4-5 minutes to start up for the first time after the system start. Once it was closed and is re-opend again, it starts up quick. I think this problem came since apple started to mess around with the JRE? Does anybody also experienced this delay? Could it be that one of the installed plugins checks for updates and causes the delay?
The major one: after eclipse is fully up & running, I can not open .py files anymore. When I open my pydev project (btw. pydev 2.7.3), eclipse freezes and I need to kill the whole thing and restart. -> I can not use it for python coding anymore, which is my primary task...
Suggestions? Re-install eclipse maybe?
Thank you for suggestions,
El
Can't really comment on #1, but for #2, can you try attaching jvisualvm to see what's going on there? (and create a thread-dump and post it somewhere so that I can take a look at it).
I'd ask you to create a bug-report for that, but the new tracker is still not up (I hope I'm able to put it up right after the funding at http://igg.me/at/liclipse is finished).
The problem was resolved by following these steps. They essentially disable one
JRE.http://support.apple.com/kb/HT5559?viewlocale=en_US
I am trying to move from Netbeans to Eclipse.
Minor thing bothering me is that Eclipse dosen't seem to have the kinda edit highlighting that Netbeans does.
For example, a new line is automatically highlighted as green. An edit is highlighted as blue. And this happens in an unobtrusive way on the left along with the line numbers( if line numbers are turned on).
Is this some configuration issue or does eclipse team not support it ?
This is specifically for MercurialEclipse plugin.
I'm a heavy eclipse user and as a general rule of thumb, it supports mostly everything. So problems like these are most likely solved through configuration and/or plugins.
Regarding your specific situation...
Maybe I'm not following your question but it seems you want to look at edits that happen on a file? When I do this in eclipse, I do so through the subversion plugin (Subclipse) and compare the existing file against a previous version in the repository (to compare against the team's older version of the file) or in local history (to compare against your own version of the file).
As in:
Also there is great article about this:
http://blog.firdau.si/2010/07/09/eclipse-quick-diff-see-what-changes-youve-made-since-last-checkout/
When I update my local working copy of an SVN repository in Eclipse using the Subversive plugin it isnt bringing any new files which have been added to the SVN repository. It thinks that the local working copy is up to date and if I ask Eclipse to update it it just says no further changes.
Anyone got any ideas why this is happening?
I just discovered this nasty problem too. It might be related to this bug report.
Deleting the entire tree worked for me too, but that hardly seems like a satisfactory solution. What scares me more is wondering how I will notice that a certain file didn't get updated, if this happens again.
Thanks to the above bug report, this worked for me (eclipse 3.7):
Team/Update to Version...
v Update to HEAD revision (=default)
Depth: Full recursive (default is Working copy)
v Change working copy to specified depth (default is un-checked)
O Ignore externals (=default)
v Allow unversioned obstructs (=default)
I do not know if that fixes the problem permanently. At least it seems a faster solution rather than full checkout.
Sorry I don't have a solution to this problem, but I have it as well, and I don't have enough cred to comment.
Here is a thread describing the same issue:
http://www.eclipse.org/forums/index.php?t=msg&th=14710&start=0&
A "workaround" I found to be successful is deleting the relevant tree (of course, backing it up first) and performing an "update". I am prompted to recreate missing files, which bring the un-added files from the repo as well. Obviously this is a terrible solution, but it does work.
Another interesting effect to note is that it is one-sided. The other machine on the repo is perfectly fine with updating new files.
I have noticed Subversive to be a bit problematic. While this isn't a direct solution to your problem, may I recommend using TortoiseSVN (assuming you're in Windows). It works excellently, has more power than Subversive, and is integrated with your shell making it a smooth transition.
It seems whenever I compare via the SVN Repository explorer (most recently after a merge) subclipse will show a few files in the compare window that have no differences whatsoever. Double clicking the file brings up the Java Source Compare window, but Subclipse highlights no sections and shows no differences. A manual inspection of the file shows they are identical. What causes this? Are there any ways to disable it, it can be quite confusing?
Your help is greatly appreciated!
Sounds like it could be whitespace-related. Maybe tortoise defaults to ignoring ws changes.
Seems to be Eclipse bug, which waits for solution...
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318826
There may not be structural change, but only space related or formatting. Try clicking on "next difference".
I think the problem is that after merging the revision of the file is changed. So, although the content of files is the same, the compare view shows the change. It is very very bad... :(
I asked a couple of coworkers about AnkhSVN and neither one of them was happy with it. One of them went as far as saying that AnkhSVN has messed up his devenv several times.
What's your experience with AnkhSVN? I really miss having an IDE integrated source control tool.
Older AnkhSVN (pre 2.0) was very crappy and I was only using it for shiny icons in the solution explorer. I relied on Tortoise for everything except reverts.
The newer Ankh is a complete rewrite (it is now using the Source Control API of the IDE) and looks & works much better. Still, I haven't forced it to any heavy lifting. Icons is enough for me.
The only gripe I have with 2.0 is the fact that it slaps its footprint to .sln files. I always revert them lest they cause problems for co-workers who do not have Ankh installed. I don't know if my fears are groundless or not.
addendum:
I have been using v2.1.7141 a bit more extensively for the last few weeks and here are the new things I have to add:
No ugly crashes that plagued v1.x. Yay!
For some reason, "Show Changes" (diff) windows are limited to only two. Meh.
Diff windows do not allow editing/reverting yet. Boo!
Updates, commits and browsing are MUCH faster than Tortoise. Yay!
All in all, I would not use it standalone, but once you start using it, it becomes an almost indispensable companion to Tortoise.
I always had stability issues with AnkhSVN. I couldn't switch everyone to Subversion where I work without an integrated solution.
Thank goodness for VisualSVN + TortoiseSVN.
VisualSVN isn't free, but it is cheap, and works a treat.
I tried version 1, and it was unreliable to say the least. I can't say anything about 2.0.
If you can afford it, the one I use, VisualSVN, is very good and uses TortoiseSVN for all its gui, except for the specialized things related to its VS integration.
#pilif: AnkhSVN maintains an in-memory state of the working copy, which is invalidated/updated by Visual Studio events (ie you edit/change a file) and AnkhSVN events (ie you commit/update/revert/etc)
Whenever the working copy is changed from outside Visual Studio (by editing with another tool, or by using another Subversion client), you will have to refresh AnkhSvn using the Refresh command we provide.
The other thing that happens when you delete a file in a project with TortoiseSvn for example, is that it remains listed in the project file, and you will have to remove it there seperately (and then commit the project file as well).
Copy/Pasting parts of my own Blogpost, as I switched from Ankh to VisualSVN:
Why did I switch? Because i was a bit unhappy with the overall stability of Ankh, since it has some problems actually tracking Solution changes. VisualSVN is “just” a TortoiseSVN Frontend, which means it leaves all the “heavy lifting” to a third-party tool that a) is installed on most Workstations anyway and b) that’s been tested and used by such a wide audience, it’s really rock-solid.
Now, AnkhSVN is certainly not a bad product, and the people behind it are serious about what they are doing, but having long-deleted files still in my SVN or getting the “Please Cleanup your solution” message get’s annoying after some time, but my biggest gripe is the property window. It’s nice that there is a nice window with Radio Buttons asking me which property I want to add. Unfortunately, there is no way to manually enter a property.
Edit: That was for AnkhSVN 1.x. In the meantime, it was updated to 2.x and much improved. I use it in production on a system where I don't have VisualSVN and it works extremely well now.
I had no problems with v1, but I was warned not to use it. I've been using v2 for a while, and I've had no problems with it. I still keep a backup of the repository though...
I started with AnkhSvn and then moved on to VisualSvn. I have my own gripes with VisualSvn but its far less trouble compared to Ankh. I'm yet to try the new version of Ankh which they say is a complete rewrite and had inputs from Microsoft dev team as well.
I've been using both the newest version of Ankh SVN and Tortoise on a project at home. I find them to both be very good with a caveat.
I've found that both SVN tools have at times failed to keep up with my file/folder renaming and moving resulting in it thinking that a perfectly good file needs to be deleted on the next commit. This is probably down to me misusing SVN in some way but TFS at work does not have this problem.
I tried AnkhSVN (1.0.3, just 4 months ago), and it did not work the way I wanted it to (i.e. needed to select things in the browser window instead of based on active file). I ended up making some macros that utilize TortoiseSVN that work much more like what I expected.
I've been very happy with using TortoiseSVN via explorer and my macros inside the IDE.
Earlier on (like 2 years ago when I last tried), AnkhSVN and Tortoise used in parallel with the same working copy caused some kind of working copy corruption where Ankh and Tortoise somehow lost track of the state the other tool left the working copy in.
It was as if one of the tools stored additional metadata not contained in the working copy and was reliant on that being correct.
The problems showed themselves by Ankh (or Tortoise) insisting on files being there which weren't, on files being changed which weren't and on files not being changed which were (and thus unable to commit).
Maybe this has been fixed since, but I thought I'd better warn you guys.
About a year ago me and a buddy used AnkhSVN for a project... several commits later while moving namespaces around, it broke the SVN repository. Broke as in, the last commit we did got corrupted, and we couldn't commit anymore.
After that we used TortoiseSVN and did the namespace moving manually, it just... worked. If you're only working on base class libraries you could always try using SharpDevelop instead (that integrates with TortoiseSVN).
I do hope they did fix AnkhSVN now though because IDE integrations always rock... when they work.
#mcintyre321
I've found that both SVN tools have at times failed to keep up with my file/folder renaming and moving resulting in it thinking that a perfectly good file needs to be deleted on the next commit.
A move or rename operation results in an delete and 'add with history' at subversion level.
TortoiseSvn shows this as:
originalFile deleted
newFile added (+)