I am looking forward to merge my code which I developed in a branch of SVN to the trunk. I am using Eclipse and I have been using Team->Commit to commit my updates to the SVN. But I haven't done a merge before. Please help me with this.
First of all make sure you are up to date. Update your working copy of the target branch, ie. where you are merging into. In this example we're working on the trunk of "core" and we want to grab the changes that have happened in the maintenance branch and merge them.
Resolve any conflicts. There should be no conflicts at this stage between the working copy and the repository.
Select the SVN merge option on the working copy. In Eclipse this is going to be found under the "Team" menu and called "Merge Branch".
SVN: Merging in Eclipse
Change the From URL to the specific branch you want to be merged into your working copy. In this example we're looking for the p400 maintenance branch (./core/branches/p400).
Change the From Revision to the last revision that was merged into the target branch. Essentially you don't want to keep merging the whole branch history, you just want to include those changes since the last time you merged. There is no easy way to determine the last merge point at this time in Subversion. You have to review your message log and look for the last commit that talks about merging. If you are disciplined about the commit messages you use for merging this should be easy (see below). Make a note of what that revision is -- you'll need this later when you commit your changes.
SVN: Merge with Eclipse
Change the To Revision to the latest (i.e. head). Make a note of what that revision is -- you'll need this later when you commit your changes.
Click Merge and wait. Depending on how big the differences are this may be quick or Eclipse my just fall over. If you have such an enormous change that you can't get it done in Eclipse you may need to make the range of revisions you are merging smaller. Or you may even have to skip certain revisions and do them manually if they are massive. We've had this problem from time to time when updating large third-party libraries. The vast majority of the time you will be fine.
Review changes and resolve conflicts. Once the merge is complete, look through the changes made to your working copy and make sure you address any conflicts you find.
Once all the changes have been resolved in the target working copy, check them in with a single commit. The reason you're not doing lots of commits is that these are changes that should have been documented in the branch from which you merged. The commit message needs to be in a specific format that details the merge and is easy to find in the future. We use the following format, but you can use anything that works for you -- as long as you stick to it.
Merging [source] to [target]; [repository]. Merge rev [start]:[end]
Enjoy!
In eclipse we have an option to merge. Right click the project , you will see "Team" option and on clicking it you will see merge option. There are three different options you can see in the merge.
To successfully merge the changes from the branch to the trunk, we need to switch the local workspace to the trunk (but make sure all the changes are committed to the branch before that). Once we do that we can use merge option and select "2 URLs" option. I put url for trunk as url 1 and the branch I wanted to merge as url 2. I could see all the incoming changes I selected "OK". All the changes are in my local now (at this point my workspace is linked to the trunk). Then I committed my changes to the trunk and hence merge from branch to the trunk was successful.
I would like to add for Point 8 .Review changes and resolve conflicts. ---
When working on conflicts manually- when you do copy from right to left on chunks of code - Be careful
Sometimes chunk of code gets added, sometimes it properly replaces the chunk.
Make sure there is no duplicate chunk of code.
Also, this is helpful-- What is the proper way to do a Subversion merge in Eclipse?
Related
I've got a project on git, assume it has the following files:
HelloWorld.java
README.md
pom.xml
I edit/commit README.md using Github's editor; no problem. Then, in eclipse using eGit, I edit HelloWorld.java, but when I attempt to commit and push that file, I get an error: non-fast-forward. Unless I do Pull first I can't commit the java file. Why is this the case? Using SVN I never had such a problem. Why does Git not allow me to commit a file when some other, unrelated file in the project is changed? I read up on this but I still don't understand the rationale behind the issue.
BTW, I'm making all changes on master for now.
That is because git is making sure your repository is up to date with the master before you commit changes. The problem is with pushing not committing. You can't push to a repository that you haven't got all the changes for. What you can do is create a new branch with your changes and merge that with the master later if you want, that is the system git uses for what you want to do.
An SVN server will do some types of merges itself, particularly when the changes are to different files as in your case. Since SVN represents branches and tags as different parts of a single tree and a single repository can contain multiple, unrelated projects this is necessary.
But git will never do a merge on the server. And since a commit represents the entire tree, your situation is a merge even though no single file was modified by both sides that need to be merged.
Even though changes being restricted to different files guarantees that there won't be any textual conflicts between them, there can still be semantic conflicts. Imagine if you're working on a change to a library function which requires all callers to be modified, and before you push that change out another developer adds a new file which contains a new call to that function. If that new file is the only change the other developer made, SVN would allow you to commit your changes and handle the merge on the server even though that will cause the code to be broken. By requiring that all merges happen under developer control, git at least gives the opportunity for this type of conflict to be caught; even though in many cases a developer may just do an automatic merge and push the results without any checking.
I've created a feature branch to work in parallel with the trunk.
In the brach I've done a big amount of structure (folder) changes. For example, I've moved folders that before were on:
application/views/scripts/users/*
to:
application/modules/user/views/scripts/users/*
Now, I'm trying to do a merge from the trunk to this feature branch and I'm founding a million of tree conflicts! And the issue is that since this tree conflicts appear, no file inside that tree is merged against anything.
I mean, I find a tree conflict on:
application/views/scripts/users (SVN message: "The last merge operation tried to modify the directory 'users', but it was deleted, moved or renamed locally")
and none of the files and other folders that were inside that path have been merged.
Is there a way to recover the "link" between the original location of a folder and the current one?
Can I do something to deal with this issue?
More than a solution, I can give a workaround, that is the one that I've used, becuase it seems that there's not really a solution for this.
After a little research I'm close to sure that SVN doesn't support this kind of feature for merging. In the documentation of TortoiseSVN it is said that:
Local missing, incoming edit upon merge
Developer A working on trunk modifies Foo.c and commits it to the
repository
Developer B working on a branch moves Foo.c to Bar.c and commits it to
the repository
A merge of developer A's trunk changes to developer B's branch working
copy results in a tree conflict:
Bar.c is already in the working copy with status 'normal'.
Foo.c is marked as missing with a tree conflict.
To resolve this conflict, Developer B has to mark the file as resolved
in the conflict editor dialog, which will remove it from the conflict
list. She then has to decide whether to copy the missing file Foo.c
from the repository to the working copy, whether to merge Developer
A's changes to Foo.c into the renamed Bar.c or whether to ignore the
changes by marking the conflict as resolved and doing nothing else.
This means that you have to decide, one tree conflict at a time, what to do. And this is not the worst part. What is really unacceptable in my case is that every time I do a new merge from the trunk to this branch I'll be forced to deal with this conflicts again.
The workaround
Replicate the structural changes made on the branch into the trunk (with its required changes on code) and make it work with them.
After commiting this changes both structures of files, the trunk and the branch will match, so later merge operation won't complain anymore.
What i understand from your issue is that you have done a lot of folder structural changes in your branch and since these changes are not there in your trunk and when you are trying to merge you are getting the error.
As per your statement, "Now, I'm trying to do a merge from the trunk to this feature branch"
At the first place when you have taken a branch out from your trunk and did the structural changes in your branch then you should merge these changes from "branch to trunk" or if you simply want to get the original structure ("recover the original location of folders")back then just revert the changes you have done in the branch.
Hope this helps.
I created a project, I added it to the repository to the trunk. I made a few changes. I'm looking for the correct way to add a new branch now. He wanted me to work a bit over the appearance of the application. Then, if everything comes out, I wanted to combine the projects into a single new version.
How to do it, ask for directions, links.
Thank you and best regards.
PS: Exactly, I mean that if you do everything as I think it is ok it shows me no call from 5 to 6 on the diagram:
image
On Subclipse subpage for graphs (http://subclipse.tigris.org/graph.html) it states:
When the cache is built, it does not gather any merge information, and when you bring up a graph you will not see any merge information. However, for any given revision in the graph, you can select it and take the "Refresh revision" option. That will go out and get the merge information for that revision, store it in the cache, and re-draw the graph. Using the toolbar, you can refresh all of the revisions on the graph at once, although performance for that option is not always great either.
So you should manually refresh revision graph in order to see 'red merge arrows'. Click on "Reload arrows" and choose "Graph revisions".
Instructions on merging and branching in Subclipse.
First, you would do an svn cp of revision one on the trunk to the branch directory. Then, svn switch to the branch and work on the changes. Once they are approved, you would commit everything to the branch, svn switch back to the trunk, and then perform an svn merge of the branch back onto the trunk. Once SVN has completed the merge, you would test the codebase on the trunk to insure it is functioning correctly and all the capability has been properly merged and do an svn commit to complete the merging of the branch to the trunk.
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
¿How would I do the operation described here, which is very simple from the command line, with the subclipse plugin?
I think I would make sure that my working copy is in sync with the branch, then I would go to "Merge...". I'm not sure what to do in the popup!
Edit: I have read somewhere that in the popup I must indicate the merge range as a range of trunk revisions: from the revision where the branch was opened, to HEAD. Makes sense. But I'm trying this out now with a test project and I don't get the new trunk changes on the working copy that points to the branch. I must be missing something, or it's not working!
Note: Subclipse 1.4.8
I got it now. It's how I said in the edit, as read in a number of websites...
in the popup I must indicate the merge range as a range of trunk revisions: from the revision where the branch was opened, to HEAD.
Apparently many people get confused with the from-to range. This is the range of revisions of the trunk/branch you're merging from. These changes are merged into the working copy you selected in the package explorer.
What I said about not getting it to work in spite of doing this was due to my mistake in selecting the trunk URL: the project was below a subfolder in the repository.
Assuming you're using the latest version of Subclipse (in the absence of information otherwise), select "Merge a range of revisions" and "Next >" -- you should be able to select the trunk (or another appropriate source) in the "Merge from:" box on the next page.