In an Eclipse (Oxygen.3a Release (4.7.3a)) java project, I merged two branches and resolved all conflicts, getting no compilation errors and all tests to pass.
However, EGit (4.9.2.201712150930-r) won't let me add deleted files to the index/stage. The button for doing so is enabled, but nothing happens when I press it.
As a result, the conflicts regarding these files are not resolved (adding to the index is required for that), so I cannot proceed with a merge commit.
The situation is as in the figure below.
What do I need to do to resolve these conflicts?
I could not solve this problem with EGit, but closing Eclipse and running
git add -A .
in the command line solved the problem (opening Eclipse again immediately showed the files to be staged). (This solution came from this answer.)
So not sure this is an EGit bug or if I just didn't know how to take this step using it. However, like I said, using the command line solved the problem.
Hello everybody I have this "big" and frustrating problem,
I have forked a project from git and as usual it is available in my account in GitHub. I then set up a project in eclipse selecting from an existing URI. All is ok, if I work with my own version of the project.
What I want to do is, because the project is changing and growing day by day, to have an updated copy from the original project and, every time I want to download any change I would like that the download is from the original project.
At the moment the only way (with EXTREMELY big problems) I found is using "Team > Fetch from Upstream" the changing the link to the repos using the "config" button. Obviously this lead to conflicts and annoying problems. I am sure that this is not the correct way to handle a forked repos and I need help.
I am using windows 7 and eclipse with egit, if I press Windows-R and then cmd it don't recognize the command "git" so I can't use console commands.
Any help?
With windows 7, you can install git to your machine and use console command as normal. (Link to download)
See this link to configure git to sync your fork with the original repo.
Hope this can help.
I am trying to checkin the project in to SVN repository. So I right click on the project then selected Team then Commit. And when I do commit I get--
Some of selected resources were not committed.
svn: Commit failed (details follow):
svn: Working copy 'C:\workspace\crawler4j\target' is missing or not locked
Any suggestions how to overcome this will be appreciated,
Sometimes, it's simply easier to open a Subversion command line client and take a look at that. I suggest that you install a command line client, go to the directory, and do a svn status. I would also look at svn info on the various directories and files and make sure they're all on the same working directory. (You can do a svn status -v to get that information).
My feeling is that the target directory should not be added or have been added to your project. This directory in Maven is used for built objects which should not be committed into your Subversion repository. Even many Ant build scripts follow Maven in this.
So, what is the status of the target directory? What happens when you do an update on the directory before committing your changes? (I believe it's Team->Update).
http://subclipse.tigris.org/wiki/PluginFAQ#head-73584410a8d4fbad6781c7b16be39f6518410a61 here you can find the solution
In Eclipse Kepler try to run Team>cleanup
[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.