A branch is technically identical to a tag, i.e. it is a copy of an existing folder at a given point in time. The two only really differ in terms of intent, i.e. what, by convention, they are intended for.
While a tag is generally intended as a static snapshot, a branch is intended to be continued to be modified subsequent to the branch operation. This allows two versions of a folder starting from a common point to diverge over time independently of one another.
This can be useful on several levels. The most common is to enable the continued development of multiple versions of a project. For example, a branch can be created for 1.0 immediately after final release. 1.1 development then immediately continues. Any high-priority issues isolated in 1.0 can then be fixed on the 1.0 branch resulting in 1.0.x maintenance releases without having to worry about changes made to 1.1 destabilizing the 1.0 code.
Branches can also be used to work on different parts of the project independently. This can be particularly useful with multi-site development.
The disadvantage of branches is that the divergence of the branches often needs to be reconciled to fold changes made on one branch back into another. For example, high-priority bugs fixed for 1.0.1 on a 1.0 branch should obviously be incorporated into 1.1. This folding is termed merging and projects can incur significant merge overhead if branches are allowed to diverge too far. Indeed, merging changes can become non-trivial if the source and destination files have been modified in parallel resulting in a merge conflict.
A branch’s ancestor refers to the folder a branch was originally copied from.
In most cases a branch’s folder will be the project’s trunk. However, larger organizations may implement more complex multi-layered branching policies where sub-branches are created from other branches, with trunk being only an indirect ancestor of a developer’s branch.
For example, a project team may be distributed across several geographical locations. The team at each location works on its own isolated branch, and each team member works on their own sub-branch of the team’s branch. In such cases the direct ancestor of a developer’s branch is not trunk, but their teams’s local branch, and their changes will have to be merged up two levels before integration into trunk is complete.
Also called a label in other version control systems, a tag uniquely identifies the state of a part or all of the repository at a particular point in time.
Subversion differs from other version control systems in that a tag is simply a folder in the repository (rather than a name assigned to a version of a folder).
A tag is created by copying a folder to a new location. For example, by convention, projects in a Subversion repository have three standard sub-folders: branches, tags and trunk. Creating a tag is generally as simple as copying trunk to a sub-folder of tags and giving it a meaningful name.
Tags can be deleted or renamed just like any other folder.
Copying a folder does not copy any of the data. Instead Subversion simply records the exact revisions of the contents at the point at which the folder is copied. This is handled very efficiently, both in terms of the disk space required and the time it takes to complete.
A project’s trunk refers to a project’s main development branch in the repository. Generally, developers working on the next main version of a project will be working on the trunk.
By convention, a project’s top-level folder generally contains a trunk sub-folder (along with tags and branches folders) which contains the latest-and-greatest version of the project at any given time. Most projects will have their developers check out working copies from trunk and commit their changes back to it.
It is common for development teams to utilize branches to develop features in parallel and in isolation from one another. Such branches are termed feature branches.
This strategy can be used to implement a stable trunk policy where only complete and stable features are integrated into the trunk, with all other significant development taking place on isolated branches.
A maintenance branch is a branch which is created for the integration of bug fixes and minor modifications which will be published as maintenance releases.
Maintenance releases usually branch directly from trunk and are created as part of a product’s release process.
For example, during the release of version 2.0, a 2.0.x maintenance branch is created. Bugs fixed as part of continuing 2.1 development are then merged from trunk to the 2.0.x maintenance branch.
Subsequent 2.0.x maintenance releases are created from the 2.0.x branch instead of trunk.