I'm in a lot of trouble.
During a composer update, somehow, the git process crashes and I have lost all my edits since last commit. It looks like there was an hard reset of my repository.
In eclipse I can find all the history files but I have to iterate on every file to check if it was changed and get the last version.
Unfortunately the massive "restore from local history" on the project doesn't work for edited file but only for deleted.
Is there any way to browse eclipse history and get all the last versions?
I know there are inside .metadata.plugins\org.eclipse.core.resources.history but they are hashed and probably I have many version of the same file.
Related
I deleted a file from my Eclipse work space but that file is in SVN repository. Could any one help me to get my deleted file from SVN without using the command line?
There's a simpliest way to recover the file with Eclipse+SVN only.
Go to SVN Repositories view, find a folder your file was located, make a right click and choose Show History. You will see the list of commits to THIS FOLDER in the History view. Please make sure it's switched to Remote Revisions. From the list of commits find a commit that deleted the file. In the pane below there's a list of files involved with this commit - you can find deleted files with minus sign. Double click will open this file in editor...
If you've deleted the file in Eclipse, Eclipse has told Subversion to mark the file for deletion. This means the next commit will delete the file. You'll have to do a revert.
If you've deleted this file via Internet Explorer or some other file browser, and didn't tell Subversion, then the file isn't marked for deletion. Simply updating the file will bring it back.
This is where the command line client sings. With the command line client, I could tell Subversion to update or revert a nonexistent file. With a GUI, I would first have to select the file, then tell Subversion what to do. But without a file, I can't do anything.
Easiest solution: Recreate the file. The contents are not important. It can be empty or contain a dirty limerick for all you care. You're basically making a file you can select with your file browser.
Then, you can select the file and tell Subversion and/or Eclipse via the Team menu to revert it. This way, it doesn't matter how the file was deleted. Subversion will restore the file back to its original checked out version.
Along the lines of Bryn's solution, using Subclipse, find the delete 'D' entry for the file in SVN history, right-click and do "Copy..." which will then ask you to specifiy a location in your Eclipse workspace. Click OK, it will probably take a little while, and that's it.
I first tried "Export...", but that didn't work for me, seems like subclipse is looking in HEAD, even though an older revision was selected.
I was following the remarks from this SO Post to "Update" my working copy with the lastest revision checked into our SVN repo.
This made perfect sense as it is the same way I would do it using TortoisSVN. Click Update and you get most recent updated files. However, there was a file I deleted from JBoss Developer (eclipse) and was expecting that using the Update option in JBDS would restore the most recent version of that file from the SVN
However, instead it just told me a conflict existed (file deleted from working copy, but exists on repository) and did not download it like it would with TortoisSVN.
So my question is - how do I get it to update where it actually redownloads the file I deleted?
With TortoiseSVN, if you simply delete a file then it becomes "Missing". If you delete a file in Eclipse, it tells Subclipse you deleted the file so it runs svn delete. The equivalent of taking the Delete action in TortoiseSVN. When you do an update, missing files are restored in your working copy, but deleted files are not -- because you said to delete it.
You are getting something else though. In your case, there was a newer version of the file in the repository. Because it is marked deleted locally, that is a tree conflict. If you did the Delete action in TortoiseSVN you would see the same.
The tree conflict is so that you are aware that the file you deleted has been modified by someone. So maybe you want to reconsider the delete etc. The Team > Show Tree Conflicts option will show all tree conflicts and provide option to resolve it.
I have been working on a raketask using Rubymine and Git. I have been using SourceTree to push my changes up to github.
I accidentally chose the "remove" option in source tree for the file I have been working on. This method apparently makes the file "irretrievably lost" which doesn't give me much hope. Is there anyway to recover the file? It was not committed nor pushed up to github yet, and the file is not in my local trash.
Try Restoring a File from Local History.
Oh man, this just happened to me and came upon this.
What I did was (on Windows) right click the directory, properties, and went to previous versions tab. Luckily windows had a backup of just a couple minutes before I deleted it. I was very happy :)
I know that you can track changes to renamed files from a repo to it's clone. However, I seem to have an issue when I rename a file to a file name that is already being tracked. In essence, I want to copy over a tracked file.
Files in original repo:
application.txt
special.txt
Then clone the repo, delete application.txt and rename special.txt to be application.txt
I would expect that the next time I made changes to special.txt in the original repo, the changes would carry over to application.txt. However, it doesn't. I get this message
local changed special.txt which remote deleted
use (c)hanged version or (d)eleted?
Trying this same thing out in Git seems to have the same results. Renaming a file to a brand new name has no issues while trying to rename a file that has already been 'taken' causes conflicts. Is there any way around this?
I wouldn't really call this a bug, as you have for all purposes just changed the contents of a file that mercurial is already tracking. Mercurial tracks files by file name and extension, and you could make the case that this is no different than just replacing the entire contents of the file.
I just had this problem in a real world project with Mercurial. GIT is also seeing bogus conflicts (special.txt deleted and updated).
Bazaar has proper rename support and it merges this case correctly (changes to special.txt are carried over and application.txt get updated as expected).
The problem with Bazaar though (at least for me) is that it lacks IntelliJ support. There are 2 plugins, the most recent has not been updated for 3 years, and last time i tried it was unusable with recent IntelliJ versions.
Since "bzr mv" and "bzr rename" need to be invoked by the IDE at the time of refactoring, the lack of support makes Bazaar unusable for me.
If you want IntelliJ support for this, vote here: http://youtrack.jetbrains.com/issue/IDEABKL-5344
[answer auto-selected by bounty system against my will]
I'm using subclipse, and always when delete a folder in Eclipse, and try to commit it, the following errors raise:
svn: Item <folder> is out of date
svn: DELETE of <folder>: 409 Conflict (http://myintranet)
Deleting and commiting via command line works fine, but what's wrong with doing it via subclipse? Is anyone more experiencing this problem?
(I experienced this problem in Ubuntu 9.10 and 10.04; last Eclipse version; and subclipse 1.4 - as the next versions of subclipse have much more bugs)
--updated: Its when I delete folders, not files
Isn't that addressed by the Subclipse FAQ?
Whenever you see "out of date" in an error message it means that the revision of the item in the repository is newer than the copy in your local working copy.
The solution is always going to be to run an update, so that your working copy is up to date with the repository, and then do the commit again (assuming that the update did not generate any conflicts).
For files, this is usually pretty easy to understand how and why this happens.
However, Subversion also versions folders, and it is usually with folders that this problem most often happens.
Subversion does not allow you to delete/rename a folder OR change its versioned properties, UNLESS the local copy of the folder is at the HEAD revision of the folder in the repository.
Your next question might be:
"OK, I can maybe understand that, but why is my folder out of date? I am the only person working in this repository."
That is a valid question, the answer lies in the way that Subversion works.
When you commit a change to a file, the revision of the file in your working copy is updated to that new revision when the commit completes, however the version of the parent folder(s) of that file is not updated.
This is because there may have been adds/deletes to other files in that folder and until you have run an update, the folder is not really at that new revision.
This is called "mixed revision working copies".
In summary, the answer is always to do an update so that the folder or file is updated to its HEAD revision.
About "Mixed Revision Working Copies":
One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers.
One of the fundamental rules of Subversion is that a “push” action does not cause a “pull,” nor vice versa.
Just because you're ready to submit new changes to the repository doesn't mean you're ready to receive changes from other people.
The fact is, every time you run svn commit your working copy ends up with some mixture of revisions.
The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in between), your working copy will contain a whole mixture of revisions
(and that is why, I believe, you cannot reproduce your "out of date" message on subsequent commits with folder deleted: your update did solve the "mixed revision" state.)
Mixed revisions have limitations
You cannot commit the deletion of a file or directory that isn't fully up to date.
If a newer version of the item exists in the repository, your attempt to delete will be rejected to prevent you from accidentally destroying changes you've not yet seen.
i think if you UPDATE before that it should work.. it did work for me
There's a simple solution without installing some extra software. I also had this "problem" and what you can do is the following:
1) open the SVN Repository view
2) there go to the folder you want to get rid of and delete it
3) go back to the java view
4) update the folder in your project you actually deleted / update your project should also work
That solved the problem in my case, as updating only retrieved the files I deleted
Subclipse has many problems like this. It works 90% of time, and then it just DOES NOT work as it should! I am using subclipse, since it is very well integrated into eclipse, and when I have problem or some bigger moves needed in svn (like merging some branch) I use Tortoisse.
I had the thing with directory like you. Then I just run the TortoiseSVN like #luiscolorado suggests, and it helped. Tortoise is so great tool (it has many great features for diffing, applying patches, getting patches and so on.).
Today I had a problem when I have removed a file, and someone had changed the same file! Then subclipse shows conflict (up to this point everything is ok), so I wanted to revert! But then the revert button is missing (disappears when inconflict mode!) so I have to do merge, and merge does not work, throws some kind of error. I didn't bother to read (maybe I should read and file it as a bug to subclipse maintainers ;-(), I knew the tortoisse will work, and you know what, it worked. There was a REVERT option.
So #Tom Brito, try command line, try Tortoisse, and then you can look at the subclipse changelog and file a bug. I think that subclipse just forgets to show us some directory changes and updates (or it is designed not to do it?), but I may be wrong.
Tom,
You might want to try TortoiseSVN, and manually update the project workspace. Find the location of your project directory in your hard drive, and then try TortoiseSVN (or the command line if it's your preference) to do the update.
A frequent cause of this problem is to delete the directory without "informing" SVN. For instance, if you manually delete the directory using the operating system instead of using SVN, you will have this problem.
If you removed the directory before you installed the subversion plug-in, but the project already existed in the repository, you will experiment this problem. A solution, in this case, would be to recreate the directory, updating/committing, and then delete again the directory.
Good luck.
My solution to this was
Delete all items in folder
Commit to repository
Update folder to HEAD
Delete folder in Eclipse
Commit to repository
A bit cumbersome, maybe, but it always works
The only working way in same cases is via command line. The subclipse is still not perfect..