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.
I am working on a Java project in Eclipse and I use SVN to commit various versions of it in the repository. However I have noticed, that when I delete a class and I then commit the project, the old class is still included in the latest committed version of the project. Is there any way to prevent the SVN from maintaining classes which have been actually deleted?
Update: The same problem comes out when I rename a class and then I try to commit the new version of the project. It keeps both classes and stores both on the repository version. How can I prevent it from storing the old ones? I appreciate deeply any help bacause I would not like in any case to store it spoiled with the old classes.
If you use an Subversion for Eclipse like SubClipse then deleting a file in Eclipse will automatically schedule the file for deletion on next commit.
If you use a Subversion client outside of Eclipse you will have to delete the file using that client and then refresh the project in Eclipse after the file is gone from your working copy.
You need to also delete the class in svn as well, something like:
$ svn rm path/to/class.java
You can also remove the file using Eclipse, assuming that you have the svn plugin installed. Make sure that you select the file when you are committing your changeset, otherwise the deletion won't be sent to the server.
Update: Answering the update to the question
$ svn mv path/to/OldClass.java path/to/NewClass.java
Or, as Martin mentioned, ensure that your have your subversion plugin in eclipse properly configured, then it will also do the svn rm and svn mv commands for you.
SVN needs to know about any changes for all files and folders that are controlled by SVN (i.e. that are put under version control). It is easy to detect file changes, but it is not easy to detect rename and delete operations. If you just delete a file (using your operating system tools), SVN will warn you about a missing file.
For these operations you must use the corresponding SVN commands. SVN is best learned, when doing it manually with all those SVN commands (at first).
Using a SVN client makes it a little easier for you. For example, if you use TortoiseSVN, you can right-click a file and choose "SVN delete" for doing both, deleting the file and communicate it to SVN. Same for renaming.
The same is done by using a SVN plugin in Eclipse (Subclipse or Subversive, for example). If you then use Eclipse for deleting or renaming a file, the plugin will also do the operation and communicate it to SVN.
Keep something in mind: When deleting or renaming files (and/or folders) - using SVN commands, of course - you should always do a SVN update prior to SVN commit. Otherwise you might get an error about a revision problem.
I am trying to rollback to a previous version of the file/folder Settings.bundle. A file was added to Settings.bundle/en.lproj. If I just delete it I just keep getting missing file warnings (and I don't want to). So now I am trying to rollback, but it seems to do nothing when I try to run the command:
svn merge -r 15:5 ./Settings.bundle/
Any thoughts?
Should work so far according to Undoing Changes in svn red book. Maybe it's worth trying to run svn delete on those files added since revision 5 (sounds like you don't need them any longer), commit it and perform svn merge again.
Alternatively you can do it manually by running svn export of the Settings.bundle to a temp directory. Afterwards svn delete on all files added since revision 5 and copy files from temp dir back to your working directory. Now you are ready to commit revision 16.
[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..
Eclipse + Subversive plugin
On commiting a directory which is out of sync with the SVN a message pops up:
Merge conflict during commit
svn: Commit failed (details follow):
svn: File or directory '.' is out of date; try updating
svn: resource out of date; try updating
Tried to update the whole project from Eclipse Navigator view (right click>Refresh or F5) and the problem still persists.
Is there something that can be done in this case?
You are mixing up two different operation in Eclipse:
Update (from version control)
and
Refresh
"update" means retrieve the most recent version of a file(s) from the version control system. "Refresh" just means that Eclipse will update its view of the local filesystem, in case a file was changed outside Eclipse.
You need to do an update (Team->Update).
You should update, resolve conflicts, then commit again.
See this link for help on resolving conflicts in eclipse.
Sometimes eclipse+subversion gets a bit lost and a more robust solution is called for:
Copy the code with changes to a different location (preferably via copy and paste).
Replace with latest from repo (or revert) on the directory giving the problem
Copy the changes back (via cut and paste again) and check in.
try to delete .svn/all-wcprops. maybe it will help
Someone else has modified this directory on you.
You need to do a svn update to get the latest version before commiting.
svn update
or
right click > Team > Update
Refresh or F5 will only re-read what's currently checked out and check for local changes, i.e. changes made outside of eclipse.
The svn update command pulls any changes made remotely (commits) down to your workspace.
You need to do an svn update to make sure you are completely up-to-date before committing.
svn update
If the update does not work, you may need to do a cleanup.
svn cleanup
You should be able to find both of these commands in your SVN client outside of Eclipse if you are using one.