I'v tried to merge a hotfix of my current deployed release branch into my develope branch.
Intellij found only the changes that were in the hotfix.
eclipse on the other hand found additionally some changes between the release and the develope and put them on the unstaged files.
Why is there a difference between the 2 IDEs? Do they use different git merge or diff? Do they choose different common ancestors?
Thank you!
No, IDEs don't have anything to do with GIT internal commands.
I think it was a mistake from your own side. I suppose you have two local repos for two IDEs, right?
May be you accidentally merged with different branch.
You said eclipse put some files to upstaged change, may be there's a conflict to that merge. Resolve it.
Using Win7 and TortoiseSVN, I created a plugin, followed the directions for first committing trunk, then created a branch/tag at /tags/x.y.z.
Except I forgot to update the version number at /my-plugin/trunk/my-plugin.php before I committed trunk and tagged the new revision.
The revision shows up in the plugin tags and as an alternative version -- but not the current stable version on wordpress.org/plugins/my-plugin/. Wordpress.org doesn't recognize it as the current stable version, even though I wrote it as such in readme.txt, perhaps because it still has the old version number at /my-plugin/trunk/my-plugin.php and /my-plugin/tags/x.y.z/my-plugin.php.
I want to either
a. delete the bad revision at /my-plugin/tags/x.y.z so I can recreate it correctly, or
b. edit/update the bad revision at /my-plugin/tags/x.y.z.
I tried switching to /my-plugin/tags/x.y.z so I could merge trunk to x.y.z, but I got this message:
Switch E:\subversion\wordpress plugins public\my-plugin to http://plugins.svn.wordpress.org/my-plugin/tags/x.y.z, Revision HEAD
'http://plugins.svn.wordpress.org/my-plugin/tags/x.y.z' shares no common ancestry with 'E:\subversion\wordpress plugins public\my-plugin'
What did I do wrong, and how can I fix it?
Easy way:
checkout tag
fix version number
commit
Whenever I commit some code to my SVN repository and then do a Synchronization again with the repository the "Team Synchronizing" panel shows me that there is a update to be taken on my code and it shows 0 files and just an "empty update" to update to the latest revision number (the revision number of the recent code commit which I did) in the eclipse. I am on Windows 7. I have used the same tools in Mac and it works fine. Whenever I do a commit in Mac Eclipse it automatically updates it self.
Is this a bug or is there something I am missing?
Any help would be appreciated.
I suspect that although you have Eclipse on both Mac and Windows, the SVN plugin, or the SVN connector used by that plugin, is different between your two setups.
I'm afraid I don't have details to hand, but have seen this behaviour before. The SVN integration in Eclipse makes most sense if you end up with no incoming changes after you do a commit. It seems one of the Eclipse plugins decides after commit to immediately poll for any outstanding changes. It sees that the top-level folder for your project has been updated, so marks it for update.
This is an accurate reflection of what happens in SVN - if you commit a new revision is created in the repository, but your local checkout is not at that revision until you do an update. If you run "svn info" on the command line just after a commit you will see this.
I commit something (new files) in subclipse using eclipse indigo and immediately it shows them as incoming and asks me to update. It tells me that I modified them!
This seems strange to me in subversive when you commit something, it's commited it doesn't show those same files you just commmited as needed to be updated if no one changed them.
Any ideas?
That's a bug in subclipse. Sometimes after commit it just seems to override the files you committed from your workspace with the previous version of those files from the repository.
I found this old bug in the issue tracker (http://subclipse.tigris.org/issues/show_bug.cgi?id=77), which seems to be related, but i'm not sure if this is the same bug.
[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..