If you don’t know what branches are and why they’re used for, read this first.
First make sure your project follows the standard SVN folder structure, i.e. the
branches folders. All your code, resources, dependencies, and everything else you might need to compile a version of your software should live inside the
Before creating a branch, perform an update on your
trunk folder and commit all pending changes. If your using Tortoise SVN a green checkmark overlay should appear on your folder. You’re ready to branch your
- Select your
Then you’ll be asked to name the new folder (actually you’re naming the branch). Use any convention you like — maybe
feature-Ticket12345or something more human-readable as
fix-CrashAfterEmptyInput. I like to use prefixes, such as
fixfor bug corrections, and
uifor user interface tweaks.
At this time, you have a full copy of your
branches/your-branch-name. To add it to your SVN just right-click it and commit. Don’t forget to ignore build-generated files.
A branch is just a parallel copy of
trunk. Your branch is isolated from the
trunk changes and vice-versa. Feel free to develop wild stuff on your branch. At any time, anyone can checkout the
trunk folder in order to commit or build something and they won’t get affected by your changes.
Both a team or an individual may work on a branch. If you’re working alone you don’t have to worry about locking files, but if two or more developers are working on the same branch, locks work as they did on
trunk. Keep in mind that locks made on
trunk do not affect other branches’ locks and vice-versa.
In conclusion, you may lock, commit, or update as you did on any regular
Keep it up-to-date
Now this is where it starts getting interesting… and tricky. Remember the isolation between
branches? That’s a (dis)advantage. Sometimes you need to update your branch with the developments made on
trunk. However, you don’t want to create a new branch or lose the work/commits you already have on your branch.
Example: You’re working on translating your application. Someone commits on
trunknew forms. Those forms need to be translated too, but when you created your branch they didn’t exist. How can your branch receive those new forms (commits) without ruining your work?
Updating your branch with the most recent version of
trunk is called “merge” on SVN, while git calls this process rebasing. For newcomers this may cause confusion since “merge” is also what you do when you definitively integrate your branch into trunk. Right now you’re not actually merging anything definitively — you’re just “updating”, like you did when you were at
- Ensure your branch does not have uncommitted changes.
- Right-click over the branch folder you want to update (not the parent
branchesfolder). Select TortoiseSVN > Merge….
- A wizard window will appear.
- Select Merge a range of revisions. Next.
- On URL to merge from type the URL to the
trunkfolder. Then select All revisions, since you want to update your branch with all revisions of
trunksince your last update. Next.
- At merge options you’ll probably want to leave all the defaults. You can press Test merge to do just that — TortoiseSVN will give you a preview of the actions that will be applied during the merge (add, remove, update, conflict), without changing any local or remote files.
- If you’re comfortable, do it, press Merge.
At this point, your local branch is a merge between what you had and the latest developments on
trunk. You may want to run a couple of tests just to guarantee that SVN’s auto-merge didn’t break anything. If your merge produced conflicts and you had to manually resolve them, them YOU MUST test all code involved in those conflicts. You’ll thank me later.
Your branch continues equally awesome after the merge? Great, then it’s time to commit your branch, and continue your work. TortoiseSVN will even suggest a commit message, a concatenation of messages from the commits that you just finished merging.
The more often you merge with
trunk, the less code you’ll have to merge each time, thus reducing the probability and complexity of conflicts.
Integrating a branch into trunk
The time has come. You developed and tested an awesome feature at your branch in (almost) complete isolation. Now it’s time to merge those equally awesome lines of code into the
trunk. The process is basically the same as updating a branch, except this time you’re updating your
trunk with the commits of your branch.
- Ensure your
trunkdoes not have uncommitted changes. And that you finished working on your branch. And that you just finished updating your branch with the latest version of trunk. And that the stars are all aligned.
- Right-click over the
trunkfolder. Select TortoiseSVN > Merge….
- A wizard window will appear.
- Select Merge a range of revisions. Next.
- On URL to merge from type the URL to a specific branch folder. Then select All revisions. Next.
- At merge options leave the defaults.
- Press Merge.
Like when updating your branch, your local
trunk is now a merge between what it had and your branch’s developments. Since this is the
trunk, run all necessary tests before commiting. After commiting your new
trunk you may safely delete your branch. If you find a bug, just create a new branch and repeat the process.
Conflicts are the flavor of life. Imagine Lord of the Rings without the all those ugly orcs and Uruk-Hais — pretty tasteless right? A conflict happens when you and someone else edit the same line of code differently. The next time you try to merge both code sources a conflict will arise, since SVN doesn’t know which line of code to use. Who’s right? Your line or your colleague’s?
In this cases you have to manually resolve the conflict. That means reviewing the file where the conflict happened and choose which version is legit. In this example, I made a change on
trunk and a different change at the same line on
branches. When I tried to merge the branch into the
trunk this happened:
SVN tried its best to merge the files but we ended up with two conflicting files. Time to put on the gloves and click Edit conflict. TortoiseSVN will open a 3-pane window with your local version (mine), the repository version (theirs), and the merged file preview.
Focus only on conflicts by navigating using the Previous/Next conflict arrows. Have a look at the Merged pane (bottom). SVN is telling that line
this.lblRepo.Text = "you're at TRUNK"; was removed and replaced by… well, SVN needs help deciding, it has two possible candidates, as you can see in the Theirs pane (left) and Mine pane (right).
You can either right-click the line full of
??????????????????????? or press the Use block button located at the Ribbon. Both will allow you to specify which block of code to use. In this case, I decided to Use text block from ‘mine’ (since after the merge I’ll be on trunk, so that’s the message I want to keep).
After you resolve the file’s conflicts you can press Save and close the window. You will return to the SVN dialog box where you decided to edit the conflict, except this time you’ll click Resolved. Rinse and repeat for the remaining files with conflicts.
Remember to test your code after a manual merge.
What started as a green window is now blue, and the developers working at
trunk were never disturbed by intermediate or unstable commits — all thanks to the power of branches.
As a last step you should delete the branch. Its code is already on
trunk, its revision history on SVN, so you no longer need it. Delete it now and avoid confusions later.