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.
Related
OK, I admit that I must have screwed up when I started using EGit. I started using Eclipse Galileo as a welcome alternative to Notepad edit and command-line compilation. Somewhat later I discovered that Git was integrated into Eclipse, and happily started using it.
I do not remember all the details, but it seems that I made an initial mistake that has been carried on from one computer to another and one Eclipse upgrade to another.
I have consistently tried to specify that source files are in project subdirectory src and their products are in project subdirectory bin. Git wants to archive anything in bin, as well as project metadata at the same directory level.
In the past I have been so mono-focused on the project that I just sprinkled gitignore files everywhere and clicked on "Ignore" when preparing a commit. But now that the project has been brought to a dead halt due to problems in Eclipse Kepler I have resolved to try to disentangle the mess while upgrading to Eclipse Luna.
As I see it, there are three alternatives: (1) Figure out a way to separate the various directories, (2) Brute force copy-and-paste the 300 some-odd source files into a new, clean directory structure (complicated by the fact that there are currently four open Git branches and several uncommitted changes) or (3) copy the current mess and continue to deal with extraneous "changed" files.
Alternative number one is of course the most desired.
Any suggestions?
(Later)
Please be patient with me. I am a newby in this venue. But quite experienced in other venues, where I learned to search for similar questions before posting.
I did try to search for similar problems, to no avail. I also noticed that, while composing my question, there appeared a list of other questions that might be related. None seemed applicable, so I ignored it. When I came back to see if there were any answers, there was the list again and this time I found Eclipse + EGit: clone project into workspace. Perhaps it was there at the top of the list when I finished composing. I'll know to look next time.
I tried the first recommendation, cloning via EGit from the current location to a new one. It seemed to work okay, but there are a couple of things missing: Only the specified branch is available (not MASTER) and the extensive history for the last three years is reduced to one entry dated at the time of cloning.
Fortunately, the other three branches (including MASTER) are not currently divergent. If necessary, I can manually create them again - if there is some way to recover or display the complete history in the clone.
I was not surprised to see that the several unstaged changes in the source were not present. I can deal with those manually, but I wonder if it would help if I staged them before my next attempt to clone?
(Staging those changes may or may not be possible. I became very frustrated with problems using Eclipse Kepler and gave up trying to do anything more to resolve the problems several months ago. I did not document the problems, and by now have forgotten what they were. I have a vague memory of trying to commit current changes and running into fatal errors.)
Now I think I have a more focused question - or rather several questions:
(1) When upgrading Eclipse to a new version, is EGit cloning the easiest way to continue an existing project on the same disk? Should I just copy the original directory? Should I first clone to GitHub and then clone back to the disk from there?
(2) Should I attempt to stage the uncommitted changes before cloning?
(3) Why is Git history reduced to one entry? Would it help if I let MASTER be the default branch and then what? Check out the current (rather lengthy) branch? Or something else?
(4) What should I do about .project, .settings and other configuration files? Is it okay to copy them into the new directory structure in the desired places? Or should I make note of all settings and reconstruct them in Eclipse Luna?
I am using Eclipse Juno (4.2.1) with SVN Kit 1.7.5.v1, Subversion SVN connection 3.0.0.20121013-170. I've checkout of my trunk and I want to compare (diff) with my branch, so that I can review my code changes. however, each time I try to generate, it fails with following error :
Generate file in unified diff format was failed. svn: E125007: Path
'/home/user2/projects/Trunk-2 (.../home/user2/projects/Trunk-2)'
must be an immediate child of the directory
'/home/user2/projects/Trunk-2 (.../home/user2/projects/Trunk-2)'
I've tried to generate diff from command line as well, still same error. Actually diff is generated but it's not proper unidiff and tools such as Jira Crucible do not accept the diff file.
Any idea why I might be facing this issue?
This seems to be bug with Jira FishEye+Crucible, however, I've resolved the issue with a workaround.
Resolved the issue by:
Delete property change lines such as :
Property changes on: /Validator.class.php
Deleted: svn:mergeinfo
Reverse-merged /Validator.class.php:r8387-8842
Reverse-merged /Validator.class.php:r8746-8979
Reverse-merged /Validator.class.php:r8860-8862
FishEye+Crucible seems to have some issue with property changes and merge info in Diff/Path files, so it's better to remove them.
Optionally add \ No newline at end of file at the end of the file.
Doing above have resolved problems for me, I hope this to be useful for someone facing same problem.
Cheers
Ravish
[SOLVED] Somehow, I managed to not have "write" permissions to the .git directory. So was trying to write the commit and getting bounced.
I've been using Eclipse for a few months, but had been just running git from the CLI. I decided that was inefficient and that I wanted to use eGit, so I started following this tutorial (http://www.slideshare.net/loianeg/using-the-egit-eclipse-plugin-with-git-hub-2578587?from=embed).
I'm trying to add an existing project, so I did Team-->Share Project-->Git and selected the .git corresponding to my project. Eclipse seems to have picked it up, okay, but when I try to commit, I get a popup saying
"Committing changes has encountered a problem' -- an internal error occured.
When I click details, it say "An internal error occurred
Exception caught during execution of commit command"
...I don't even know where to start on this one. I googled the error and didn't get anything useful.
Anyone know how to fix this, or at least how to start debugging?
I've solved my case removing index.lock file from the git folder of the project.
start debugging?
Check the "Errors" Eclipse view for a full Stack Trace associate with that error message
Example of an Error View:
fix it?
If the Exception is a NPE one (NullPointerException), like shown in bug 329611, then you can try a git commit -m "a message" in a shell, in order to get past that initial first commit with a GUI.
As the OP rogueleaderr mentions, the error view and the exact stack trace behind the exception was enough:
Somehow, I managed to not have "write" permissions to the .git directory.
So was trying to write the commit and getting bounced.
I face this problem too, Error tab doesn't show anything more.
So I use GitExtension to commit instead, problem solved.
Using parallel eGit and GitExtension to keep tracking a local git repo is a good idea. It's update runtime on both Eclipse and GitExtension when we make change on each.
I faced this problem. I delete the .git folder and .gitignore file push to upstream it works correctly.
I had this same issue. I resolved it by committing manually from terminal using (in this order):
git add . then git commit and lastly, git push from the local repo directory.
I faced similar problem, It was resolved after deleting index.lock file in .git\ folder.
I'm trying to create to create a tag in svn repo for my project. I use Eclipse and Subversive plugin. Every time I try tagging, I get the following error:
Tag operation for some of selected resources failed.
svn: Commit failed (details follow):
svn: No write-lock in '/home/project/directory'
Where /home/directory is a directory in my project. I'm pretty sure that if I would delete the project and re-checkout it, then all will work.
Does anybody know what is the source of the problem and if there is a workaround to get it working without delete-checkout cycle?
Thanks for raising this issue! I just ran into this with Subversive 2.2.2 on Eclipse Indigo (3.7).
Cleaning up repository didn't work, but I noticed that the local copy has an old revision number (like 2, where the current is 37), although I am sure I committed before tagging.
So I ended up replacing the local code with the latest from repository, which updated the revision number. After that tagging worked like charm.
You find that error popping up from time (2008) (to time (2009)) to time (2010).
Since there isn't any answer, that usually means the problem got away (like relaunching Eclipse was enough to pass that ordeal).
It could be a permission issue, or a resource (like a file or directory) blocked by a process.
But if it is more complicated, you still have the command-line alternative (a svn copy)
VJ. reports in the comments:
I eventually tried svn update which explained me that the write lock is present in another path of SVN.
So I issued a svn clean for the from the root tree. Which cleared the issue.
Post that, svn update worked as well as svn switch.
You need to delete the File called 'lock' in the .svn Directory, then svn should work again.
regards.
You need to Clean up your project.
Right Click > Team > Cleanup
Then you can Switch to any branch you want
same issue here(just tried to create a branch instead of a tag in this case). check out the ultimate solution :
1) commit the code.
2) disconnect the project from SVN.
3) delete the project from the workspace.
4) check out the project.
5) try again.
voila!
its a bit overkill, but this works 100%
For me the solution was a simple "svn up" at the top of the project directory.
[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..