What do "branch", "tag" and "trunk" really mean?

Question

I've seen these words a lot around subversion (and I guess general repository) discussions. Myself I have been using svn for my projects the last few years, but I've never grasped the complete concept of these directories.

What do they mean?

Answer 1

In SVN a tag and branch are really similar.

Tag = a defined slice in time, usually used for releases

Branch = also a defined slice in time that development can continue on, usually used for major version like 1.0, 1.5, 2.0, etc, then when you release you tag the branch. This allows you to continue to support a production release while moving forward with breaking changes in the trunk

Trunk = development work space, this is where all development should happen, and then changes merged back from branch releases.

Answer 2

They don't really have any formal meaning. A folder is a folder to SVN. They are a generally accepted way to organize your project. The trunk is where you keep your main line of developmemt. The branch folder is where you might create, well, branches, which are hard to explain in a short post. A branch is a copy of a subset of your project that you work on separately from the trunk. Maybe it's for experiments that might not go anywhere, maybe it's for the next release, which you will later merge back into the trunk when it becomes stable. And the tags folder is for creating tagged copies of you repository, usually at release checkpoints.

But like I said, to SVN, a folder is a folder. branch, trunk and tag are just a convention.

[Edit] I'm using the word 'copy' liberally. SVN doesn't actually make full copies of things in the repository.

Answer 3

The trunk directory is the directory that you're probably most familiar with, because it is used to hold the most recent changes. You main code base should be in trunk.

The branches directory is for holding your branches, whatever they may be.

The tags directory is basically for tagging a certain set of files. You do this for things like releases, where you want "1.0" to be these files at these revision and "1.1" to be these files at these revisions. You usually don't modify tags once they're made. For more information on tags, see http://svnbook.red-bean.com/en/1.4/svn.branchmerge.tags.html

Answer 4

@Nick

Really? All development should happen in Trunk? When you're doing that how do you ensure that Trunk always contains releasable, working code? I can understand for bug fixes or very small items, but from my experience anything beyond changing a couple lines of code should probably be done in a Branch and then merged back in to Trunk once it has been tested.

Answer 5

I'm not really sure what 'tag' is, but branch is a fairly common source control concept.

Basically, a branch is a way to work on changes to the code without affecting trunk. Say you want to add a new feature that's fairly complicated. You want to be able to check in changes as you make them, but don't want it to affect trunk until you're done with the feature.

First you'd create a branch. This is basically a copy of trunk as-of the time you made the branch. You'd then do all your work in the branch. Any changes made in the branch don't affect trunk, so trunk is still usable, allowing others to continue working there (like doing bugfixes or small enhancements). Once your feature is done you'd integrate the branch back into trunk. This would move all your changes from the branch to trunk.

There are a number of patterns people use for branches. If you have a product with multiple major versions being supported at once, usually each version would be a branch. Where I work we have a QA branch and a Production branch. Before releasing our code to QA we integrate changes to the QA branch, then deploy from there. When releasing to production we integrate from the QA branch to the Production branch, so we know the code running in production is identical to what QA tested.

Here's the (software)">Wikipedia entry on branches, since they probably explain things better than I can. :)

Answer 6

Hmm, not sure I agree with Nick re tag being similar to a branch. A tag is just a marker

• Trunk would be the main body of development, originating from the the start of the project until the present.

• Branch will be a copy of code derived from a certain point in the trunk that is used for applying major changes to the code while preserving the integrity of the code in the trunk. If the major changes work according to plan, they are usually merged back into the trunk.

• Tag will be a point in time on the trunk or a branch that you wish to preserve. The two main reasons for preservation would be that either this is a major release of the software, whether alpha, beta, RC or RTM, or this is the most stable point of the software before major revisions on the trunk were applied.

In open source projects, major branches that are not accepted into the trunk by the project stakeholders can become the bases for forks -- e.g., totally separate projects that share a common origin with other source code.

Answer 7

The trunk is the development line that holds the latest source code and features. It should have the latest bug fixes in it as well as the latest features added to the project.

The branches are usually used to do something away from the trunk (or other development line) that would otherwise break the build. New features are often built in a branch and then merged back into the trunk. Branches often contain code that are not necessarily approved for the development line it branched from. For example, a programmer could try an optimization on something in a branch and only merge back in the development line once the optimization is satisfactory.

The tags are snapshots of the repository at a particular time. No development should occur on these. They are most often used to take a copy of what was released to a client so that you can easily have access to what a client is using.

Here's a link to a very good guide to repositories:

• Source Control HOWTO

The articles in Wikipedia are also worth reading.

Answer 8

@Power-coder

Yes all development should happen in the trunk. When the trunk is feature complete to the specifications it is branched and put in to testing. During testing and production all coding is done on the branch, and new coding for the next release/specification is started on the trunk. This ensures that the production team can work separately from the new development team.

Answer 9

Here's a good article I ran across explaining how/when to use trunk, branch, and tags. I'd not used source control before, but this article made it pretty easy for a noob like me to understand. Day-to-day with Subversion

Answer 10

I think that some of the confusion comes from the difference between the concept of a tag and the implementation in SVN. To SVN a tag is a branch which is a copy. Modifying tags is considered wrong and in fact tools like TortoiseSVN will warn you if you attempt to modify anything with ../tags/.. in the path.

Answer 11

Tag = a defined slice in time, usually used for releases

I think this is what one typically means by "tag". But in Subversion:

They don't really have any formal meaning. A folder is a folder to SVN.

which I find rather confusing: a revision control system that knows nothing about branches or tags. From an implementation point of view I think the subversion way of creating "copies" is very clever, but me having to know about it is what I'd call a leaky abstraction.

Or perhaps I've just been using CVS far too long.

Answer 12

No one here really has it right, or has stated it in a clear way. I'll describe probably the most common usage scenario of branches and tags, and give an example scenario of how they are used.

• Trunk: Main development area. This is where your next major release of the code lives, and generally has all the newest features.

• Branches: Every time you release a major version, it gets a branch created. This allows you to do bug fixes and make a new release without having to release the newest - possibly unfinished or untested - features.

• Tags: Every time you release a version (final release, release candidates (RC), and betas) you make a tag for it. This gives you a point-in-time copy of the code as it was at that state, allowing you to go back and reproduce any bugs if necessary in a past version, or re-release a past version exactly as it was. Branches and tags in SVN are lightweight - on the server, it does not make a full copy of the files, just a marker saying "these files were copied at this revision" that only takes up a few bytes. With this in mind, you should never be concerned about creating a tag for any released code.

For example, let's say you start a new project, so you're working on what will be 1.0 in trunk. Once 1.0 is finished, you branch trunk into a new "1.0" branch, and create a "1.0" tag. Now work on what will eventually be 1.1 continues in trunk.

You come across some bugs in the code, and fix them in trunk, and then merge the fixes over to the 1.0 branch. You may also get bug reports for 1.0, and fix the bugs in the 1.0 branch, and then merge them back to trunk. Sometimes a bug can only be fixed in 1.0 because it is obsolete in 1.1. It doesn't really matter, the only thing is you want to make sure that you don't release 1.1 with the same bugs that have been fixed in 1.0. Once you find enough bugs (or maybe one critical bug), you decide to do a 1.0.1 release. So you make a tag "1.0.1" from the 1.0 branch, and release the code. At this point, trunk sill contains what will be 1.1, and the "1.0" branch contains 1.0.1 code. The next time you release an update to 1.0, it would be 1.0.2.

Eventually you are almost ready to release 1.1, but you want to do a beta first. In this case, you likely do a "1.1" branch, and a "1.1beta1" tag. Now, work on what will be 1.2 (or 2.0 maybe) continues in trunk, but work on 1.1 continues in the "1.1" branch. Once you release 1.1 final, you do a "1.1" tag from the "1.1" branch.

You can also continue to maintain 1.0 if you'd like, porting bug fixes between all 3 branches (1.0, 1.1, and trunk). The important take away is that for every main version of the software you are maintaining, you have a branch that contains the latest version of code for that version.

Another use of branches is for features. This is where you branch trunk (or one of your release branches) and work on a new feature in isolation. Once the feature is completed, you merge it back in and remove the branch. The idea of this is when you're working on something disruptive (that would hold up or interfere with other people from doing their work), something experimental (that may not even make it in), or possibly just something that takes a long time (and you're afraid if it holding up a 1.2 release when you're ready to branch 1.2 from trunk), you can do it in isolation in branch. Generally you keep it up to date with trunk by merging changes into it all the time, which makes it easier to re-integrate (merge back to trunk) when you're finished.

Also note, the versioning scheme I used here is just one of many. Some teams would do bug fix/maintenance releases as 1.1, 1.2, etc, and major changes as 1.x, 2.x, etc. The usage here is the same, but you may name the branch "1" or "1.x" instead of "1.0" or "1.0.x".

Answer 13

I know I come after the battle, but I still would like to present my view of those concepts (under a community owned answer so I am not here for the karma ;) If you have enough rep', edit this post and make it better).

In general (tool agnostic view), a branch is the mechanism use for parallel development. An SCM can have from 0 to n branches. Subversion has 0.

• Trunk is a main branch recommended by subversion, but you are in no way forced to create it. You could called it 'main' or 'releases', or not have one at all!

• Branch represents a development effort. It should never be named after a resource (like 'vonc_branch') but after:

  • a purpose 'myProject_dev' or 'myProject_Merge'
  • a release perimeter 'myProjetc1.0_dev'or myProject2.3_Merge' or 'myProject6..2_Patch1'...

• Tag is a snapshot of files in order to easily get back to that state.
  The problem is that tag and branch is the same in Subversion. And I would definitively recommend the paranoid approach:

  you can use one of the access control scripts provided with Subversion to prevent anyone from doing anything but creating new copies in the tags area.

A tag is final. Its content should never change. NEVER. Ever. You forgot a line in the release note ? Create a new tag. Obsolete or remove the old one.

Now, I read a lot about "merging back such and such in such and such branches, then finally in the trunk branch".
That is called merge workflow and there is nothing mandatory here. It is not because you have a trunk branch that you have to merge back anything.
By convention, the trunk branch can represent the current state of your development, but that is for a simple sequential project, that is a project which has:

• no 'in advance' development (for the preparing the next-next version implying such changes that they are not compatible with the current 'trunk' development)
• no massive refactoring (for testing a new technical choice)
• no long-term maintenance of a previous release

Because with one (or all) of those scenario, you get yourself 4 'trunks', 4 'current developments', and no all you do in those parallel development will necessarily have to be merged back in 'trunk'.

Answer 14

i am really confused, what would be the best way to understand trunk branch tag, as i have an exam and unsure what they really mean and how to categorize each part... any help

Answer 15

Now that's the thing about software development, there's no consistent knowledge about anything, everybody seems to have it their own way, but that's because it is a relatively young discipline anyway.

Here's my plain simple way,

trunk - The trunk directory contains the most current, approved, and merged body of work. Contrary to what many have confessed, my trunk is only for clean, neat, approved work, and not a development area, but rather a release area.

At some given point in time when the trunk seems all ready to release, then it is tagged and released.

branches - The branches directory contains experiments and ongoing work. Work under a branch stays there until is approved to be merged into the trunk. For me, this is the area where all the work is done.

For example: I can have an iteration-5 branch for a fifth round of development on the product, maybe a prototype-9 branch for a ninth round of experimenting, and so on.

tags - The tags directory contains snapshots of approved branches and trunk releases. Whenever a branch is approved to merge into the trunk, or a release is made of the trunk, a snapshot of the approved branch or trunk release is made under tags.

I suppose with tags I can jump back and forth through time to points interest quite easily.

Answer 16

•Trunk: Main development area. This is where your next major release of the code lives, and generally has all the newest features.

•Branches: Every time you release a major version, it gets a branch created. This allows you to do bug fixes and make a new release without having to release the newest - possibly unfinished or untested - features.

•Tags: Every time you release a version (final release, release candidates (RC), and betas) you make a tag for it. This gives you a point-in-time copy of the code as it was at that state, allowing you to go back and reproduce any bugs if necessary in a past version, or re-release a past version exactly as it was. Branches and tags in SVN are lightweight - on the server, it does not make a full copy of the files, just a marker saying "these files were copied at this revision" that only takes up a few bytes. With this in mind, you should never be concerned about creating a tag for any released code.

Answer 17

http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-best-practices.html

Answer 18

I have a blog post about this exact topic. http://www.sublimesvn.com/blog/2009/11/what-are-branches-tags-and-trunk-in-subversion/