I've recently updated IDEA and now can't find neither unshelve feature, nor shelves view. Where are they?
Shelving works fine, I see patch file. But the only way to restore it is to take this file from IDEA secret folder and perform "Apply patch" with it. Is it OK?
Often after an upgrade (especially when you install to a different directory) IDEA loses its index of what patches were on the shelf.
Thankfully, the patch files are still there - IDEA just doesn't remember about them any more.
Look in your .IntelliJIdea/config/shelf directory and you should find some .patch files (each one named after with the name of the changeset that you shelved).
You should be able to "Apply Patch" these files from your CVS menu like normal patch files (that's all shelve/unshelve does anyway, nothing fancy going on - I've done it before and it worked fine).
If you haven't changed anything about your installation, the .IntelliJIdea directory should be in your home directory (not sure, I always change mine to sit underneath my IDEA install directory).
Related
I'd like to set some specific options in idea.vmoptions and idea.properties for IntelliJ IDEA 14, but I don't have access to those files in C:\Program Files\... (yes, that's Windows, don't troll ;)
Is there a folder in %UserProfile% or an environment variable I could set to read those files (both vmoptions and properties!) from elsewhere?
Please don't suggest to copy the whole IDEA folder elsewhere, there's a reason why I can't access it. I would be interested in a Linux solution too, the same would most likely work on Windows.
My Research
For Mac there're specific instructions at Increasing Memory Heap, but for Linux and Windows it's just filename which are trivial to find out anyway.
I also found IntelliJ IDEA files locations, but it says can be modified in IDEA_HOME\bin\idea.properties which doesn't help since I can't access that file, but want to change properties in it.
Update: Simple Answer
Create IDEA_PROPERTIES and IDEA_VM_OPTIONS environment variables and point them to the files you want, restart IDE, done.
Also see documentation for more (and maybe report that it lacks any mention of IDEA_PROPERTIES).
You can use %USERPROFILE%\.IntelliJIdea14\idea%BITS%.exe.vmoptions on Windows as custom options file. I tried it and it works.
Another way that I haven't tried, but I think should work, is to copy idea.bat and edit it to use the file you need.
I have a computer with two hard drives. In the first one, an SSD disk, I have Windows partition (C) and on the second one (D), a raid volume, I install all the programs. I also moved my user folders (desktop, documents, downloads, pictures and videos) to D:/Users/David.
After installing IntelliJ Idea on D:/Program Filles(x86) a .IntelliJIdea13 directory appeared on D:/Users/David. No problem with this as all was working nice. Then I installed Scala plugin, created a new SBT project and build it. After this, the .sbt directory used by SBT was in C:/Users/David/.sbt but the references to the libraries in my project are pointing to D:/Users/David/.sbt. The question is, how can I force IntelliJ Idea or Scala plugin to download the libraries to D:/Users/David.sbt?
Not 100% sure if this can be a solution, you can change the HOME folder of Intellij IDEA. Look for the folder where the idea executable is. In Linux I have on
~/applications/idea13/bin
On Windows you can check the properties of the menu item. There should be file idea.properties that contains the home folder location of the idea files.
You can find more information here that describe more details:
Locations can be changed by editing the following file:
IDE_HOME\bin\idea.properties
Follow the comments in idea.properties file to change the defaults,
make sure to un-comment the lines defining these properties:
idea.config.path
idea.system.path
idea.plugins.path
idea.log.path
On the other hand you can change the location of your project to D:/Users/David. you should also have a look inside the project folder, there should be a .idea folder with has a library directory. They contains the location of the libs used in the project with their paths.
As dawez allready answered, you should edit idea.properties to set config, system, plugins and log paths.
But if you want to change the user.home path, then you must edit idea.exe.vmoptions file. Just add the following at the end of the file:
-Duser.home=your_new_user_home_path
If you use idea64.exe then you should edit idea64.exe.vmoptions file.
JetBrains had added complete set of features to support such a case and this is described here:
Changing IDE default directories used for config, plugins, and caches storage
How to save/restore Sublime Text 2 configs/plugins to migrate to another computer? states that, to backup a Sublime Text 2 installation, a user should preserve the ~/Packages/User directory (from the user's local data folder on whatever OS they're using).
However, http://andrew.hedges.name/blog/2012/01/19/sublime-text-2-more-sublime-with-a-drop-of-dropbox and most other walkthroughs for using Dropbox to sync Sublime's settings specify three directories: ~/Packages, ~/Installed Packages and ~/Pristine Packages.
What is the functional difference between backing up just ~/Packages/User, and the other 3 directories?
I think that Packages/User is the one in which you are supposed to put settings (according to Sublime's official and unofficial documentation). However, some people put them in the other folders from time to time.
The Dropbox advice may be a hedge against poor practice.
From here:
Installed Packages is:
You will find this directory in the data directory. It contains a copy
of every sublime-package installed. Used to restore Packages.
These are the packages installed as sublime-packages. I don't think package control uses this, but if you install something as a sublime-package maybe you want to keep it?
Pristine Packages is:
You will find this directoy in the data directory. It contains a copy
of every shipped and core package. Used to restore Packages.
So essentially a list of .sublime-package files used to restore if you break something.
Packages is:
The packages used by Sublime Text, either installed as part of sublime, or the plugins.
User is:
The user directory is your personal directory, containing configurations, additional snippets, etc.
Below are my personal views on what to save, so feel free to ignore it if you would like.
I would have to agree with the post saying just save the User directory, as Package Control will grab all of the plugins in the list if they aren't already installed. I didn't see this mentioned in that post, but you can also add repositories (by specifying a URL) to Package Control, which allows you to install Packages outside of those submitted to Package Control, but still hosted somewhere. One of the arguments I can see to saving the Packages directory completely is if you are using plugins that aren't hosted anywhere (though these could probably be moved to the Packages directory without any problems).
The Installed Packages and Pristine Packages are used to restore packages, so I wouldn't think these would be needed, but I'm sure there is some use case where it is.
Anyways, realize I got off topic a bit at the end there, but hope everything before that helps clarify.
After IntelliJ IDEA froze and was killed from the task manager, all the Run/Debug Configurations disappeared. I have tried invalidating caches, reloading files from disk, synchronizing and restarting, but nothing helped.
You can try to restore your Run configuration using the Local History feature of IntelliJ IDEA.
If you are using .idea directory based format, then your configurations will reside in workspace.xml file under .idea directory, invoke Local History dialog from the .idea directory right click menu in IDEA Project View, select the label some time before the crash and revert the old copy of workspace.xml.
In case .ipr file based format is used, your configurations will be stored in the <project>.iws file in the project root which you can restore in a similar way.
If the configurations were Shared, they are stored in .idea\runConfigurations directory as separate XML files or in the <project>.ipr file (if old project format is used).
If the Local history is blank and you are in Windows, try Restore previous versions right clicking the workspace.xml file or the <project>.iws one in Windows Explorer.
You can go to your main project and right click on it, select local history --> show history. Find some point in time where you think that system was stable (before crash) and click revert. This worked for me.
To me, this frequently happened on switching branches. Turning off "restore workspace on branch switching" helps to prevent the run configurations from getting lost.
Edit: Not sure if it actually has an impact, it still seems to happen to me sometimes, maybe less frequently though. I'll leave it here since the answer already has some upvotes, so maybe this was the solution for someone...
For every project in intellij there's a file created with all the configurations related to it.
Under the root directory of the project there's a hidden folder .idea in it is the workspace.xml with the configuration. workspace.xml is comprised of components one of which is responsible to hold the run/debug configurations.
If this file is getting corrupted it's difficult to restore these configurations if you don't have a backup of workspace.xml. to overcome it:
1. in intellij right click the workspace.xml file under project view and choose Local History -> Show History
2. if there's no history you can copy the component from a coworker with similar configurations.
3. backup in advance the workspace.xml and retrieve the RunManager component from it..
another good choice is to use the share option.
under each project's definition there's a checkbox share
Marking this checkbox will extract the definition for this project to an external location:
under the same .idea folder a new folder is being created runConfigurations and the configurations per project are being represented there in xml files.
The advantage of using share is that it can be copied and used for similar projects under other branched like QA and production
In my case, i've accidentally pressed Alt + Home and this bar disappeared, this combination toggles run bar at the top of IDEA window for me.
Here the screen with my bound actions on this keys. I hope it should help
Run configurations are stored in your project files. When IntelliJ (or your computer with IntelliJ running) crashes hard, the project files can become corrupted and unreadable. I don't know of a way to recover this unless you have your project files are backed up somewhere.
Navigate to your project folder and check weather any .idea folder is created or not,
if created copy your project and paste it other location ant try opening it;
it will work.
I sometimes have the problem that all the run/debug configurations are not created from CMake after being lost. I solved this by just deleting the whone list of configurations from the workspace.xml (from .idea folder).
This happened to me recently and I just restarted IntelliJ and they shared ones (in .run) are now restored.
In my case what happened was I did something that made IntelliJ recognize the project as a new application type, so it thought my old configuration was not valid for my project anymore and wasn't displaying it to me. I reverted my changes and the configuration appeared as an option again.
I guess this feature can't be removed from IntelliJ but I guess this can help:
Run/Debug configuration functionality might be hidden, so to show it go to:
View/Appearance/Navigation Bar
Very annoying problem in Intellij Idea for many years.
It's quite often breaks because of broken (connection to?) Ant debugger, used to create run configs.
I was periodically searching for a solution, but no success. Then today after disappeared Run Config to display in panel I did inspect contents of workspace.xml. All the run configs were there.
And then it turns out to be 7+ years bug clue...
Always spring out non-called Ant...
Happily, contents of workspace.xml in place with all your run config items, you can just
disable infamous plugin Ant debugger,
reload the project,
and all your run configs are displayed and available again))).
Happy to share with all of you the solution).
I was wondering if I right click on a file in the SVN repo browser, does it get permanently deleted? can it be recovered?
This question/answer from the SVN FAQ might interest you :
How do I completely remove a file from the repository's history?
There are special cases where you
might want to destroy all evidence of
a file or commit. (Perhaps somebody
accidentally committed a confidential
document.) This isn't so easy, because
Subversion is deliberately designed to
never lose information. Revisions are
immutable trees which build upon one
another. Removing a revision from
history would cause a domino effect,
creating chaos in all subsequent
revisions and possibly invalidating
all working copies.
The project has plans, however, to
someday implement an svnadmin obliterate command which would
accomplish the task of permanently
deleting information. (See issue 516.)
In the meantime, your only recourse is
to svnadmin dump your repository, then
pipe the dumpfile through
svndumpfilter (excluding the bad path)
into an svnadmin load command.
If it's that hard, there are little chances it can be done easily from Tortoise SVN...
(And it's not the goal of Source Control...)
You'll find that you can only delete from the Repo Browser when you are viewing the HEAD revision. This is identical to deleting a file from your working copy and then checking in the delete. In both cases, you'll be able to restore from the previous revision.
Deleting a file via the repo-browser context menu basically creates a new global revision where just that file was deleted, so it appears in the log as such - you can always revert to that revision to get the file back, or you can just pull it directly from the repository into your working copy.
No... Deleting a file (even using the repo browser) only affects working copies. It would be a pretty lousy revision control system if you couldn't recover a file from the past. It is actually pretty difficult to modify files in a committed revision, even if you have root access to the server.
Doesn't right-click just bring up some sort of menu? And with SVN is that you can always revert anyways.
I deleted a top level directory from Repo Browser by accident and the only way to get it back was the following:
Export the top level folder from a previous version history
Make a new folder in the repository to replace the one deleted.
Add the exported files back to the new directory (same name as previous)
Update the working copy, it will delete and then re-add the same files.
Its annoying but at least the working and repo will be back in sync. The "Revert Changes from this Revision" didnt work for undoing repo deletes, it only reverts in working directory not the "Undo" the delete to the repository.