Every time I look for a file using the files finder console the file does not show up as a result of the search despite its existence in the project.
At certain point this feature was working but I may have change some configuration in Rubymine involuntary. Any help it's welcome!
That's a known issue already fixed: https://youtrack.jetbrains.com/issue/IDEA-266391
Builds with the fix will be added to that issue so you can follow it.
As a workaround, please try invoking File - Invalidate Caches (still the issue might come back).
Pretty much what the title says. For whatever reason projectile-invalidate-cache does not remove dead files from projectile's cache, or at least not from the results it presents me. I am using Spacemacs, an extension of Emacs, but I believe this issue is specific to projectile.
Restarting the editor does not fix the issue.
One thing to try would be to make sure you are running projectile-invalidate-cache from the project you want to clear out files for (i.e., from a buffer that is visiting a file in that project. From the docs for projectile-invalidate-cache:
Remove the current project's files from `projectile-projects-cache'.
Note it is supposed to work only for the "current project".
However, I have also not had much luck with this command (potentially this is me not using the command correctly). What I often end up doing is deleting the actual cache file (in my case this is ~/.emacs.d/projectile.cache. I have not noticed any negative effects of this, and your cache will be rebuilt without the deleted files next time you use projectile.
If your project is a git project, try to commit your change. It works for me.
Actually the correct path of projectile.cache file to be removed is: ~/.emacs.d/.cache/projectile.cache
I installed through MELPA, and deleting ~/.emacs.d/projectile-bookmarks.eld did the trick for me.
I am trying to compare my svn branch with its working copy in SVN, using Subclipse. When I launch the compare, I get this dialog box with nothing in it (I blurred out the names of my projects to protect my company).
Has anyone else come across this error that knows how to fix it? Is this a known bug?
Are you using a really old version? Current version is 1.8.6, but a version like 1.6.17 would also be relatively current. I recall this problem back in 2005 but it was fixed. That said, I also recall the issue with the empty error dialog had something to with Eclipse whenever an exception happened inside the compare process. So most likely we tracked down the exceptions and fixed them. I imagine if there is some new way to get an exception that could cause the same behavior.
I would start by making sure you are current.
Is Eclipse's undo history broken? I have been using 3.1, 3.2, 3.3, and now 3.4 versions for the last few years and was always able to undo only about 20-25 changes back in history.
This nonsense has cost me some lost modifications countless times when trying to revert some recent changes (if you reply with "you should commit to svn every 25 changes", I'm going to unleash dragons on you).
There's a setting in Preferences->Editors->Text Editors->Undo history size and I set it to 1000 but it didn't help anything.
I'm mostly using Eclipse with the Perl E.P.I.C. in the Perl Perspective, if it matters.
So guys, what's the problem and how do I fix it?
I'm experienceing the same problems and I am also using Eclipse with EPIC.
It seems this is a known issue with EPIC, see http://sourceforge.net/tracker/index.php?func=detail&aid=1728227&group_id=75859&atid=545274
Reported in 2007, so I'm surprised it hasn't been fixed :(
Edit: Yay! This is now fixed in EPIC version 0.6.37
Testing show that for low values of the property it does indeed work - I'm using the Java Editor.
Perhaps you can try and see if the Java Editor respects those settings - I'm too lazy to make > 50 changes and undo, and if it does file a bug against E.P.I.C.?
Not a direct answer, but Eclipse maintains a local history of edited files (Context menu -> Restore from local history). Maybe that would be a better way than going back 25 steps in the undo-history.
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 (+)