I was working on a project in IntelliJ, where I put in some code to delete some files from my project. This accidentally deleted the whole project from the filesystem (Windows 10). The only file left is the .idea directory that probably stores some IntelliJ configuration. The Local History option in IntelliJ has been disabled ever since (which means it wiped the Local History of this project), so there is no way of recovering the project via Local History either.
I used recovery programs like Recuva and EaseUS which for some reason didn't recover the lost files (EaseUS in particular shows files from 2 or 3 days ago instead of today).
I also doubt I can recover these files via Git since Git does not use a single file to store its history.
Any suggestions?
Related
I'm new to JavaFX 8 and the IntelliJ IDE. I have a JavaFX8 project that works but not as I would like. I'd like to try another approach but the substantial changes may not work. I don't want to loose code I have working.
To save code I have working, I've been creating a new project and then locally copying all the folders(.idea, out, src) and files except .iml, of the working project into the appropriate folders in the new project with the newly generated .iml.
This always seems to work but is it proper procedure?
I'm not on a team of developers and have yet to learn Git/GitHub.
Please advise. Thanks.
Maybe you should learn how to use a Version Control System like Git, then you can create a project repository and have different branches for things you want to try out. Keeping the working code in your master branch will prevent you loosing your working code. Also, when using a vcs you can always revert to versions of your code that have been working. The IntelliJ Idea IDE has perfect support for working with all different types of version control systems. If you don't want to learn any forms of vcs then there is no other way to "backup" your working code.
Is it proper procedure? It's probably not how most people would go about achieving what you want to achieve but it's certainly workable. If you wanted to stick with that for simplicity now, I'd copy the whole directory structure, delete the .idea and .iml files, and then create a new project in IntelliJ on that clean copy: IntelliJ will automatically set up folder structure based on the existing source without you having to go through any additional manual setup.
If you're willing to experiment with the git route, to achieve the basics of what you want to achieve is not very complicated and I've written a small quick-start below. IntelliJ offers very good support for Git, and once your repository is created you can do everything you need from the IDE. I'm going to assume you're working on Windows, although the steps shouldn't be too far removed on other platforms.
Install Git
You can download and install Git from https://git-scm.com/download/win, which will install a command shell called Git Bash.
One-off setup for your project
Open up git bash and go into the directory containing your source. Rather than seeing separate drives as Windows does, Git Bash assumes there is a logical 'root' directory under which all your files are accessible. Your C: drive will be /c. To move around you can use cd to change directory (using / instead of ) and ls to list files instead of using dir.
Assuming your source code is in C:\projects\myproject:
cd /c/projects/myproject
git init
The second line above creates a git repository in that directory. This doesn't affect your code, it just creates a folder called .git that contains all of the book-keeping information.
You don't want to have every file under version control - in particular you don't want your build outputs. You need to set up a file in your project directory called .gitignore which tells git which files and directories should be ignored. As a starting point you can copy https://github.com/github/gitignore/blob/master/Java.gitignore and rename the file to .gitignore
Basic Commands and committing your initial version
There are a small number of basic commands:
git status
Running git status will tell you which files have been modified, which are not under version control, and which files have been added to the staging area to be committed next time.
git add path/to/file
This adds a file to the staging area waiting to be committed. You can add multiple files to the staging area before committing them in one go.
git commit -m "description of your change"
This commits all of the staged files as a new version, which the specified commit message.
If you go into your project directory, do a git status and check through the list to make sure there's nothing you don't want to have under version control, then you can do git add . to add everything to the staging area and git commit -m "Check in initial version of the source code" to commit it to the repository.
After you've committed, you can run
git log
To see a history of all of the changes. IntelliJ has a view that will show you the same thing.
Creating an experimental branch
This is where git shines; if you want to try something experimental you can create a branch of your project while allowing git to preserve the original version.
git checkout -b experiment1
Will create and switch to a branch called experiment1. You can delete, rename, move, rewrite and develop whatever you like on this branch. The changes you commit will be independent of your original working version.
You can switch back to your original version (preserving all of the changes you've committed on that branch) using:
git checkout master
Where master is just the name of the default branch created when you ran git init. The experimental version will still be there and can be switched to again using git checkout experiment1 or from IntelliJ using the branch selection in the bottom right corner of the status bar.
If you decide that the changes you've made in experiment1 are to become your new "good" version, you can merge them back into the master branch and repeat the cycle from there.
I'm looking for a way to control versions of my project through IntelliJ. However, I know Git can manage it the best way and I already did started experiencing Git with the help of Madara Uchiha's Git tutorial. I must say it is incredibly useful, but I rather have version control arranged on my harddrive which is constantly backed up.
I decided doing my version control manually and it's pretty slow and annoying. Is there an easier and more efficient way to clone the current project files in another folder?
For example, clone the current project files on another folder named v1.4.2 outside my project structure without relocating my project files, also having them refactored as project on its own so they be runnable whenever.
Set up a local Git repository for the project. It will start with a master branch. Then create a working branch that you make your changes in. You can merge this branch back in to master as you are ready. You can create as many branches as you need and switch between them very quickly. All using the one directory.
If you are new to git you can use something like Sourcetree - (a GUI for Git) it will allow you to manage the repository. It makes it really fast to switch between branches of your repository. It also helps with pushing changes to another location. GitHub, Bitbucket, etc.
For backup, you could always set up the project on Bitbucket. You can create public and private repositories for free. I really recommend setting this part up.
Depending on the environment that you are building on, you could build a shell script / batch script that would copy files to the duplicate location. Without knowing what type of project you are developing in/for it is hard to say what would be the best strategy.
Ideally if your project has a build output you could have the compiler/IntelliJ IDEA place the results into your result folder. You could then copy the results to your Builds/v1.4.2 folder or wherever. Whether you check in the files that are built will depend on your project. You can always exclude files/folders like your ../Builds that you don't want to track via your .gitignore file.
I have IntelliJ IDEA 13.1 running on a number of machines, all with identical paths for the project and modules but different local user names. The .idea directory gets committed to the git repo. When I make changes to my Global Libraries those are not reflected on the other machines because that info is in
C:\Users\user\.IdeaIC13\config\options\applicationLibraries.xml
I want changes to Global Library settings to be required only once and applied everywhere.
Should I tell IDEA to look for applicationLibraries.xml under the .idea directory instead of in the local user's directory which is not under version control? how?
Solution was to go into Project Structure, right click on each Global Library and choose "Copy To Project Libraries..." then remove the original from Global Libraries. Then in each project remove the old global library and add the newly created project library. This way library data is stored in the .idea dir and not the user's dir.
The applicationLibraries.xml file, among others, are stored in a platform-dependent folder in the repo, for example in _linux or _windows. If this is your problem, read on.
For things like keymaps this is wanted because things work differently after all, but for libraries which either only contain jars, or contain binaries (dll/so) for all platforms, this is unwanted.
On the PC with the global libraries (assuming linux for now):
Copy the file from config/settingsRepository/repository/_linux to _windows,
Execute git add _windows/applicationLibraries.xml from the command line,
Restart IntelliJ,
Merge repo (not Overwrite remote)
This solved it for me, and now I have global libraries on all my computers, and not just my linux computers.
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.