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?
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.
Maybe I have hallucinations, but I'm pretty sure of what I'm saying (I am new to GIT): I have some java code on my local drive, never versioned (to any versioning system, neither GIT nor SVN or whatever). I've created a repository on bitbucket, then I imported the source code from local drive. I did some testing, following a tutorial. Everything worked fine since I've noticed that, in the history folder (I am using the Eclipse plugin) I could diff two older versions of a file (and have the correct diff displayed), but these changes were made BEFORE I even created the git repository (local and remote).
I cancompare two versions saved yesterday:
I![YESTERDAY][1]
I can compare two more recent versions (today):
![TODAY][2]
-- I cannot post images, not enough reputation :( --
Notice that I installed GIT (and created the bitbucket repository) TODAY!
It's Eclipse tracking the history. I have a toy Java project open in Eclipse—which has not been commited to any source control—and I am able to diff against previous versions I saved yesterday.
To see for yourself:
Create a new Java project
Create a new class file
Make several changes, saving each time
Compare with > Local history...
I am using team svn plugin in my eclipse helios pydev project.I deleted a repository file in eclipse and then committed the changes and all went well. The file got removed from repository fine.
Lets say package structure is like this in repo
dev/
folderA/
folderB/
C.py
In eclipse dev is the project name.
I deleted C.py from eclipse and commited using svn team commit option.
It worked fine.
Now when I try to compare folderA with repo folderA, Eclipse try to compare C.py from the revision which obviously is not there and does not allow compare to work.
Somehow eclipse has that file in its memory.
How can I make eclipse know that file is deleted and is not supposed to be there in first place?
it seems that was just a synchronisation problem as after updating from the repo the problem was solved.
[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..