What is a really simple "how to" to do branching and merging using TortoiseSVN?
1 Answers
Assuming your work directory is working from the trunk:
Right-click on the "root work folder" (this term always refers to Windows Explorer) and do svn update
to update your work folder to the latest trunk.
Make sure what you have is stable.
Right-click on the root work folder and do svn commit
to make sure any local changes are committed to the trunk.
Right-click on the root work folder and do svn repo-browser
.
If you don't already have a branches folder in the repository: right-click on the folder just above the trunk folder and do "create folder" and create a branches folder (for example, if your trunk is http://myserver/svn/MyRepository/MyProj/Trunk
, create http://myserver/svn/MyRepository/MyProj/Branches
).
Right-click on the trunk folder and do Copy To:
and put in the new folder name for your branch. For example: http://myserver/svn/MyRepository/MyProj/Branches/MyNewBranch
. (Don't worry that this will waste a lot of space... this is called a "cheap copy" ... it doesn't actually copy the contents of files unless they change).
Close Repo-browser.
Right click your work folder root, and do: svn switch
and choose the folder name of your new branch (for example, http://myserver/svn/MyRepository/MyProj/Branches/MyNewBranch
). Leave everything else at the default.
Now work on your branch. When you get to milestones, right-click on the root work folder and do svn commit
to commit to your branch. (This will not be seen in the trunk).
If others are working on the same branch, periodically do svn update
from the root work folder. This will update from the branch. (It will NOT get any updates from the trunk.)
Whether or not others are working on the same branch, you should periodically merge changes from the trunk to make sure your branch won't be too hard to integrate later. To do the periodic merge: right-click on the work folder root and do svn merge
. Select "Merge a Range of Revisions". Under "URL to merge from", choose the trunk (for example, http://myserver/svn/MyRepository/MyProj/Trunk
). Leave Revision Range blank and leave everything else alone. Click Next. Leave everything alone and click Merge. Make sure everything still works... fix it if not. Once you are satisfied, do a regular svn update
from the work root folder to update from the branch (this is necessary even if you are the only one working on the branch, to satisfy SVN). Then do svn commit
to commit the merged trunk changes to the branch. You can repeat this step periodically as many times as you want.
Once your branch is ready to integrate, do the above step one last time and do your final testing. Do a final commit to the branch.
Right click on your root work folder and do another svn switch
, this time switching to the trunk (for example, http://myserver/svn/MyRepository/MyProj/Trunk
). This will have the effect of essentially "undoing" all the work you've done on your branch, but don't worry... you will get your work back. (It will also report a lot of updates to files you didn't change in your branch, but these are just "SVN property" changes... don't worry about them.)
Right click on your work folder and do svn merge
. This time, choose "Reintegrate a Branch". For the URL, put in your branch (for example, http://myserver/svn/MyRepository/MyProj/Branches/MyNewBranch
). Leave the rest alone and click Next. Leave everything alone and click Merge. You now have all the work you've done on your branch, as well as up-to-date work from the trunk.
Do a final test. Everything should work because this should be the same set of files you had in your last test in the branch. Right-click on your root work folder and do an svn commit
. Commit everything, even files that you didn't work on in your branch (they just have "SVN property" changes but committing them helps SVN keep track of all the revisions).
The trunk now has all your branch work as well as all the work that was done in the trunk while you were working on your branch, and it all works. In addition, SVN has the complete history of all the files, even the revisions that were checked in while you were working on your branch.
Optional: go into Repo-browser, right-click on your branch folder (for example, http://myserver/svn/MyRepository/MyProj/Branches/MyNewBranch
) and do "delete". This will have no effect on the trunk, and you don't need the branch any more. (Even if you are really paranoid, don't worry, because you can even get your deleted branch back from Repo browser at any time if you really need to.)
Please feel free to comment!

- 30,738
- 21
- 105
- 131

- 37,465
- 35
- 132
- 205
-
37I said "simplest" not "simple" :) – JoelFan Sep 22 '09 at 18:58
-
1Thanks! You've been the first to actually thank me (although there have been upvotes and favorites :) – JoelFan Nov 23 '09 at 12:34
-
Is it correct that once you have re-integrated the branch into the trunk, you cannot perform any more work on that branch? As it won't track changes and you won't be able to merge to/from that branch anymore? – Michael Waterfall Dec 28 '09 at 19:00
-
1As far as I understand, the merge will not work more than once from the same branch. – JoelFan Dec 28 '09 at 23:53
-
See: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html for full details on why a branch should be deleted after reintegrating to trunk. I recommend reading the whole post, but the reasoning for deleting the branch is in the "Reflective/Cyclic Merges" and "Branch Management and Reintegrate" sections of the post. – Joshua McKinnon Jan 13 '10 at 19:16
-
@JoelFan can you have alook at my problem here and if you know what can be the issue http://stackoverflow.com/questions/9189780/repetive-merge-changes-on-tortoise-svn-trunk-to-branch-merge – manocha_ak Feb 08 '12 at 09:27
-
1This is really very useful one – Avil Mar 29 '12 at 10:03
-
@Avil, please vote up the question and answer if you haven't already... and also spread the word among your friends (for example via twitter). I don't think enough developers take advantage of the power of merging to make their lives easier and prevent unnecessary errors – JoelFan Mar 29 '12 at 13:58
-
@JoelFan We want to start using the mainline model, with work branches that stay alive next to the mainline (the trunk). The [TortoiseSVN docs](http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html) say this about "Reintegrate a Branch" merge option: _Once you have performed a reintegrate merge you should not continue to use it for development... The solution to this is simply to create a new branch from trunk to continue the next phase of your development._ I don't want to delete/create a work branch. Do you know any other solution. Thanks in advance. – Nick V Apr 04 '12 at 14:57
-
@NickV, Please explain more the purpose of your "work branch". The most common reasons for creating a branch are (1) to work on a feature without disrupting the trunk or (2) to maintain a released version while using the trunk to develop the next version. For (1) you will eventually want to merge back to the trunk. For (2) you will want to delete the branch once you no longer support that version. Is your purpose something other than (1) or (2)? – JoelFan Apr 05 '12 at 02:32
-
@JoelFan, for (1). Some background... We want to use [this](http://www.infoq.com/articles/agile-version-control) branching model. A rule is to catch up from the trunk every day, "merging down". So I'm looking for a fast merging down method using subversion, without too many overhead. Else I'm afraid it will not be done. The "copy up" happens after each finished story on the work branch and the work branch stays alive (in the model). – Nick V Apr 05 '12 at 08:08
-
I find that I get a large number of false conflicts if I leave Revision Range blank. My recommendation is to use the range from when you created the branch. For example, if the earliest revision of any file in my branch is 250, then I would use a range of "250-HEAD". – Nelson Jan 13 '10 at 18:52
-
I have not gotten false conflicts, but I have observed poor performance when leaving the Revision Range blank. So yes, I think that may be a valid modification to my procedure. However, it does impact the "simple" part :) – JoelFan Apr 05 '12 at 02:34
-
Usually, I skip long replies. But this one, each line is very informative..much thanks – Shanadas Mar 21 '16 at 12:00