Merging code with subversion, and things you must know
Branching and merging in Subversion is very common in large projects, but it has a reputation for being so difficult so that many developers either hate performing these tasks or do it incorrectly. Here are some questions and answers style tips to perform these tasks with a greater understanding.
Q. When will you merge code from a branch to trunk?
A. Merging from a branch to trunk is done
- When you’ve finished development in your branch, and
- When you no longer need the branch.
This process of merging code from a branch to trunk is also known as "reintegrate". The diagram below shows that "Tortoise SVN" and "Eclipse SVN client" providing the initial merge options, and reintegration is one of them. You can only reintegrate a branch to trunk, after you have rebased your branch with changes in the trunk.
Q. What are the key steps involved in merging code from branch to a trunk?
A.
Step 1: Firstly, merge trunk into your branch and commit any changes to your branch. This is a very important step as you need to make sure your branch is consistent with trunk before merging it back.
This is also known as re-basing.
You can either select a range of revisions to merge or leave it empty to merge all the revisions.
Step 2: Commit rebased changes in your feature branch to the subversion.
Step 3: Checkout the trunk.
Step 4: Reintegrate your feature branch into trunk.
Step 5: Build and test your merged code.
Step 6: Commit the code into SVN.
Step 7: You can delete the branch. As mentioned earlier, after merging a branch into trunk, the branch can no longer be used. Subversion keeps track of merges using the svn:mergeinfo property. Because of the way it uses this property, once a branch is merged into trunk it can no longer be involved in merges properly.
Tip: Copy trunk to a new branch, merge it with feature branch/s. When things done, merge the new branch back to the trunk. This technique is quite like the mercurial and git rebasing.
Q. What do you understand by the term "working copy"?
A. It is the local copy that you had checked out. Your local working copy reflects some directory in the remote Subversion repository. For example, if you had checked out from a trunk, then trunk is your working copy, and if you had checked out from a branch, then branch is your working copy. Once you make changes to you working copy, you can commit them to the SVN. If you check your local working copy folders, you will see ".svn" folders that contain info about the SVN.
Q. What if you had made a mistake during your merge?
A. You can use the "revert" function to bring in the latest code from the SVN and overwrite your working copy. This means, undoing your uncommitted changes.
You can also switch between branches and trunk.
Labels: SourceControl, SVN
2 Comments:
Dude, this is quite helpful. Thanks.
Is there a way we can automate this process. Its quite overhead every interval of time manually merging the code.
Post a Comment
Subscribe to Post Comments [Atom]
<< Home