When i do a synchronisation of files or try to commit, there are also files shown that are not changed.
This is only when i did a merge from an other workspace to the one i get those files in.
When i take a look at those files, they have no difference from the files on svn.
anyone any idea?
seems that a newer version of Eclipse solves this problem!
when merging you get a 4 step wizard and in the latest step there is an option 'ignore ancestry'
if this is clicked, there wont be taken other files into this merge and the problem isn't there.
hip hip hooray
Did you check if the SVN properties on the files changed? SVN records the semantic information (merged revision range) in a property svn:mergeinfo when using the svn merge command.
It doesn't matter whether you use svn merge on the command line or Eclipse Team. Please read the documentation on mergeinfo to see what is going on. The property will track your merge history in the repository (a significant improvement over e.g. CVS).
(Edited after comment)
Related
When trying to commit changes to git from eclipse, I often want to look, what exactly changed in the file. For some reason egit doesn't give me that option.
It only offers to compare with working tree, which makes no sense to me, since it will show no differences.
For example TortoiseGit has the option compare with base. But it is inconvinient to use external tool for making commit. Is there any solution with egit for this issue?
Double clicking on the file should open the compare view between the central repository version and local work space version of that file. Hope that helps you
I am using Eclipse Indigo and subeclipse as the svn plugin for eclipse. Now here is the situation. I was synchronizing my project with the remote repository. There were conflicts present and I mistakenly clicked on "mark as merged" for one of the files without merging it. I tried restarting eclipse and some other stupid hacks. But nothing works out. So is there a way to undo "mark as merged" action?
Mark as Merged means that the local version of the file contains the content you want, after having compared the files and manually resolving issues. Subclipse still has to update the local file so that SVN's metadata is happy, so it saves the current content of the file, runs svn update, and then replaces the file.
So you can now run Team > Revert if you want the file to match what was in the repository, or Compare with > Base Revision if you just want to examine the differences again and possibly make more changes.
Neither of Marks suggestions worked for me. The class did revert back to the original (pre-merged) state, but trying to Merge again just gave me a 'no differences detected' message.
What did end up working for me was to Compare With > Local History. I was able to pick a version that was right before I hit Mark As Merged, and that got me back to the Compare Editor view that I had during the original Merge (which showed all the conflicts). I was then able to change the code correctly, and Mark As Merged again.
Delete the local project and re-import it, and this has the effect of undoing an accidental 'Mark as Merged' action. Just make sure that the deletion won't result in loss of uncommitted work.
I'm using svn for the first time, to maintain a custom version of Wordpress. I'm using the subclipse plugin in eclipse. The time has come to merge the changes in the latest release of Wordpress with my customised code base.
I have tried creating a branch and adding the new Wordpress release there, then performing a merge. No changes were made however.
Could someone walk me through the setup of project like this? I fear I am missing something basic.
Thanks.
This is assuming you merge from branch (containing the latest version of Wordpress) to trunk (your customized codebase).
(Make sure that you have committed everything you need into branch.)
Team --> Switch to another branch/tag/revision... your working copy to trunk (the target of your merge operation), and resolve any conflicts that come up at this point.
Team --> Merge opens a dialog where you will be performing the merge operation. Change the "From" URL to reference branch (the source of your merge operation, i.e. what you want to merge into your working copy). "From Revision" should point to the revision in branch where you want your merge operation to "start" from - typically the revision that was last merged in from branch to trunk (or most likely the head revision in your case, if you really want to merge just that latest changes in branch).
Set "To Revision" to point to the latest revision in branch (= the head revision).
At this point you are ready to perform the merge - Dry run command lets you preview what will happen during the merge, and Merge will perform the actual merge.
Once the merge operation has been completed, you need to make sure that all changes that were performed against your working copy are ok, and resolve all conflicts.
When you're done with resolving conflicts and reviewing the changes, commit the changes to trunk in a single commit operation. For your own convenience, it is strongly recommended that you add a commit message where you specifically state what this commit is for ( = merging revisions from X to Y from branch to trunk, what was the purpose, etc.).
Hope this helps.
Converting wordpress project to vendor branch procedure
If you are using svn for the first time I suppose you have not started with a clean wordpress copy, branched from there and edited the branched version, have you? ;)
If that is so you might have a problem at your hands.
Background
Unlike "regular diffs" SVN merge does not compare right-side code/folders with left-side code/folders.
While svn merge might fall back to a diff-like mechanism if it does not find a history, I would not recommend relying on that as it can be quite prone to unneccessary conflicts.
SVN Merge is used to reproduce changes that have been recorded in the SVN history. It is like telling a painter "Hey you know how this picture looked before you added that tree on the hill? That Tree was great! Look here i've copied the same base picture but now it's with a sunset. Can you paint the same tree again but on this picture with the sunset?"
The painter might be able to reproduce the tree because he knows how he had done it. He might even have a draft somewhere.
The picture, that is wordpress. The painter, its svn with you commanding it. The tree thats your modifications. The picture now sunset-themed is the newer wordpress version.
What most likely you did is copy wordpress vanilla into your svn, modify it, work with it.
To stick with the picture example, the history would contain commands like "copy whole picture, add tree, add leaves".
Now you bring a new version of wordpress, a new picture so to say and put it besides your older modified version. The Problem is, you human and smart know its quite much the same picture and even though the newer verison is different you just have to copy the tree, SVN does not have that knowledge. For SVN your wordpress 1.7 folder (modified) is completly distinct from wordpress 1.8. They share no history because nothing in SVNs log indicate it. SVN is a bureaucratic snob isn't it? ;)
Now what people do to allow svn to maintain that historic connection between wordpress 1.7, your modified 1.7 and the new 1.8 is they use branching right at the beginning of their works.
So you would start off with a clean 1.7 wordpress in a "vanilla-wordpress" folder, store it in svn and branch it to, say, "my-modified-wp". There you hack away until you feel like updating wordpress from upstream. People then download the latest wordpress copy overwrite their vanilla wordpress and merge the resulting changeset.
In the picture example commands would be these:
"Buy original picture
copy original picture as my picture
draw tree on my picture
draw sunset on original picture (someone else did that for you, aka update)
*reproduce* sunset on my picture too"
You can cleanly reproduce the sunset because you know how the picture looked before the sunset was applied.
Your problem though is that you did not start that way off but edited on your downloaded wordpress right away. So your newer copy of wordpress can not be easily associated with your modified version.
One way to establish history relations
download the **exact** wordpress version you started your project with
Put it into /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.7.1" to tag the import.
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/branches/my-new-modified-wordpress" or whatever your project/WP-edition is called.
Now comes the trick part
Scroll back the svn log of your "old-modified-wordpress". The one that you did not branch. You have to find the first revision AFTER your initial import of the old wordpress. Once you found that revision you take its number and use it in the second of these two commands:
change into a local checkout of "/branches/my-new-modified-wordpress"
issue "svn merge -r **4**:HEAD http://svnserver.tld/repositorypath/my-**old**-modified-wordpress". If 4 was the first revision during which you made own modifications.
You are telling svn the following: "Take all changes in my old branch between revision 4 and NOW and reproduce them on my new branch."
If all works out you should have two identical branches. the old-modified and the new-modified with the slight difference that the new-modified has a solid history with your "/vendor/wordpress/current" branch.
This ancestry allows you to contunously do the following:
Download the wordpress version you wish to upgrade too and **overwrite** /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.9.3" to tag the new version.
change into local checkout /branches/my-new-modified-wordpress
issue "svn merge http://svnserver.tld/repositorypath/vendor/wordpress/current"
profit
This procedure I describe with less storystelling at the link allready. But before it can work you have to establish the ancestry relation between the branches.
Subversion svn:externals file override?
I know it has been alot to read :). If you plan do soem drawing, think of "change commands" not states and you'll be fine.
C
Me and my friend using flex builder (eclipse based) with subclipse for a project.
Before committing I always update but sometimes I could not commit because of conflicts. Then I use Team->Synchronize with Repository and it shows at the right side latest from repository and at the left side the my current working copy. It has a button to copy from all non-conflicts from right to left (from latest repository to my working copy). But there are still conflicting lines.
Sometimes I just want to copy from left to right but there is no button for that (I mean overwriting repository file lines with my lines). After copying non-conflicting parts from right to left I just want to commit left side (I want to overwrite and commit my final file to repository). I cannot commit because of these conflict issues. Then my friend can use Replace With-> Latest from Repository command to get latest overwrited version.
Subclipse documentation is weak I could not find any good guide on the Internet. Could you explain subclipse conflict resolution step by step for a dummy like me? A video showing the steps, or an alien technology to fix it quickly will be fine. Are there any better (easier) solution for source control for eclipse?
(I use subclipse 1.4)
Yes, you are right. There is no button for that. in the Diff View(Side-by-Side View) the items in red are in conflict. They can not be automatically merged. You must review the item in conflict and manually resolve it by copying/editing the block of code that is in conflict.
After committing to or updating from repository(Synchronize with Repository) you'll see in the Console view that some items are in conflict. When you take a look at that file in Package you'll see 3 files right next to your original file:
myfile.txt (original file)
myfile.txt.mine
myfile.txt.r3293
myfile.txt.r3501
Right-click your original file then select Team -> Edit Conflict. In the Diff View provided, edit the file on the left-side to match the final result you want. (i.e. You may want to keep some of your changes and copy over new update from the revision in SVN, discard all changes and only keep your changes, etc.) After you are done, save the file. Right click your original file again then select Team -> Mark Resovled.
You will see that the addition 3 files disappear. You can now "safely" commit your work.
There is no easy way to do this since SVN can't decide what's the best option when such conflict arise.
I know this thread is old, but if someone is looking for an updated answer, my experience can help.
I'm using subclipse 1.8. Right-clicking on the original file and selecting "Mark Resolved...", you'll have several options, among others, take the local file or the base file as the correct version. You can save time with these options.
I can't find "Mark Resolved" so instead I clicked "Mark as Merged" after manually deleting the generated files.
Do the following steps:
Copy your latest working updates to a safe place.
Select the file which has conflicts..right click > select replace with>>Select Latest from Repository.
Then go back to your saved working copy and manually replace the current file contents (which has been overwritten in above step) with yours.
Then from team select Commit...
This way conflicts should be resolved and you saved your latest updates to SVN Repository.
I'm pretty used to how to do CVS merges in Eclipse, and I'm otherwise happy with the way that both Subclipse and Subversive work with the SVN repository, but I'm not quite sure how to do merges properly.
When I do a merge, it seems to want to stick the merged files in a seperate directory in my project rather than overwriting the old files that are to be replaced in the merge, as I am used to in CVS.
The question is not particular to either Subclipse or Subversive.
Thanks for the help!
Merging an entire branch into trunk
Inspect the Branch project history to determine the version from which the branch was taken
by default Eclipse Team "History" only shows the past 25 revisions so you will have to click the button in that view labeled "Show All"
when you say "Show All" it will take you back past the branch date and show you all the history for trunk as well so you'll have to search for your comment where you branched
NOTE: if you use Tortise SVN for this same task (navigate to the branch and select "Show Log") it will show you only the branch history so you can tell exactly where the branch began
So now I know that 82517 was the first version ID of the branch history. So all versions of the branch past 82517 have changes that I want to merge into trunk
Now go to the "trunk" project in your Eclipse workspace and select "right click - Team - Merge"
The default view is the 1 url merge
select the URL of the branch from which you are merging
under Revisions select "All"
press OK
This will take you to the "Team Synchronizing" perspective (if it doesn't you should go there yourself) in order to resolve conflicts (see below)
Re-Merging more branch changes into trunk
Insepct the trunk project history to determine the last time you merged into trunk (you should have commented this)
for the sake of argument let's say this version was 82517
So now I know that any version greater than 82517 in the branch needs to be merged into trunk
Now go to the "trunk" project in your Eclipse workspace and select "right click - Team - Merge"
The default view is the 1 url merge
select the URL of the branch from which you are merging
under Revisions select "Revisions" radio button and click "Browse"
this will open up a list of the latest 25 branch revisions
select all the revisions with a number greater than 82517
press OK (you should see the revision list in the input field beside the radio button)
press OK
This will take you to the "Team Synchronizing" perspective (if it doesn't you should go there yourself) in order to resolve conflicts (see below)
Resolving Conflicts
You should be at the "Team Synchronizing" perspective. This will look like any regular synchronization for commit purposes where you see files that are new and files that have conflicts.
For every file where you see a conflict choose "right click - Edit Conflicts" (do not double click the file, it will bring up the commit diff version tool, this is VERY different)
if you see stuff like "<<<<<<< .working" or ">>>>>>> .merge-right.r84513" then you are in the wrong editing mode
once you have resolved all the conflicts in that file, tell the file to "mark as merged"
once all the files are free of conflicts you can then synchronize your Eclipse project and commit the files to SVN
I typically check out both branches and then use the compare to each other option which does a synchronize-like compare of the two source trees. After integrating the changes into one branch, you can recommit back to the repository.
Use Eclipse integration, it works perfectly fine.
The main change from CVS, is that you only merge deltas from a branch, ie changes from one revision to another.
That is to say you have to track the correct start revision somehow (unless you have svn 1.5 merge history)
If you got that right, it's only up to you to get the changes right with the compare editor.
Firstly, if you are seeing ">>>>>" and such in your files when you view them in Eclipse, this probably means that you are not looking at the file with the proper compare editor. Try right-clicking on the file in the Project view or Synchronize view and selecting "Edit Conflicts" to bring up a compare editor that will show you the conflicting regions graphically rather than as text. Note that the compare editor that comes up for "Edit Conflicts" is different from the one that you get when you just doubleclick on a file in the Synchronize view -- the doublieclick compare editor shows the differences between your current file and the way it existed when you last checked it out or updated it, while the Edit Conflicts compare dialog shows the differences between two sources of changes (for instance, the changes you merged versus the changes that existed in your workspace before you merged).
Secondly, you may wish to be aware of a bug in some versions of the Eclipse subversive plugin which causes all files that accepted merge changes to be incorrectly marked as having conflicts. This bug has been fixed, but a lot of people don't seem to have updated to get the fix yet. Further details here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=312585
Remember that with svn reverting a modified tree to a clean state is fairly easy. Simply have a clean workspace on the merge destination branch and run the merge command to import the modifications from the merge source branch, then synchronize your workspace and you will get your usual eclipse comparison window showing all the merge modified files and the conflicts.
If for some reason you can't solve the conflicts you can svn revert on the project and go back to a clean state, otherwise you do the merge in place and once you are done you can commit. Note that you don't have to commit, once you are done handling the conflicts you can also return to the dev view, verify that the code compiles, run your unit tests, whatever and then synchronize again and commit (once the conflict are locally resolved they won't come back)
last time I looked, when you use subclipse merge command it will overwrite the merged file (using conflict markers to show conflicting areas) and put the original left and right side of the merge in the same place. it shouldn't put anything in different directories.
As a rule of thumb, it is best to commit all merge modifications in a single commit and to only have the merge modifications in the commit so that you can rollback the merge later if needed.
openCollabNet's merge tool for subclipse is pretty neat. There are many merging types available and the merging I just performed with it when seamlessly. I recommend it.
The one thing that syncrhonize view in eclipse lacks is check-in capability. In Team synchronization view I can view all my changes and resolve conflicts, so it would be rather intuitive to check-in right there instead of going back to java view and do check-in.
I would advise not trying to use Eclipse's plugins as your primary access to Subversion.
If you are developing on Windows, TortoiseSVN is the best program that I have seen for Subversion access. Explore to the directory of which you wish to merge, right click on it and use the Tortoise SVN merge option. Assuming a non-interactive merge, once you get conflicts, you'll have to go through each conflicted file and edit the conflicts before marking them as resolved. For this process I recommend a program called KDiff3, which shows your local repository copy (what was stored in the .svn before the merge), your local copy (including any changes), and the copy coming from the repository, and allows you to easily see (and even hand-modify if needed) the result of the merging. It also handles a bunch of minor conflicts automatically.
KDiff3 is portable, TortoiseSVN is a windows shell extension, so if you're using another environment, I would try to just use SVN to merge. But that would be much more of a pain :)
I landed here because I was looking for a way to merge in an external merge editor (KDIFF3) but start the merge from eclipse. I wasn't satisfied with the answers provided above. So here is ho to configure kdiff3 as merge and diff editor for SVN in eclipse:
go to Windows -> Preferences → Team -> SVN -> Diff Viewer
Add a new config (add button):
Extension or mimetype: * - if you wish you can specify different mimetypes for different editors, I didn't need that thus the alquantor.
Diff:
Program path C:\Program Files\KDiff3\kdiff3.exe (or wherever you have your merge editor - sry for the windows path, feel free to add a linux version in the comments or edit this answer.)
Arguments:
${base} ${mine} ${theirs}
Merge:
Program path C:\Program Files\KDiff3\kdiff3.exe
Arguments:
${base} ${mine} ${theirs} -o ${merged}
This will probably work as well for other merge editors, but with a different argument syntax (figure it out an let us know :) ).
The usage is as usual (team->edit conflicts) for merging and compare->foo for the diff view.
Cheers