Branching and tagging are concepts common to almost all version control systems. Branch is a separate line of development that exists independently of another line. It always begins life as a copy of something, and moves on from there, generating its own history. Branches are created mainly for the following purposes: independent development of the current revision with the correction support in the release version, long-term independent work, using of source codes of other developers. All three opportunities are shown in the table. There you can also find a more detailed explanation of the algorithm for each opportunity.

Branch Release	Long, isolated work	Using of codes from 3rd vendors
[ 0] tags branches [ 1] [ 2] [ 3]---)[release, 4]-->[release, 5] | [6] | --------------[7] [ 8] / [ 9](----- [10]--->[release2, 11]--> ... [head]	[ 0] [ 1] [ 2] [ 3]----)[longwork1, 4] | [ 5] [ 6] | | [ 7] [ 8](------/ [ 9] [10]-----[longwork2, 11] | [12] | [13] [14] / [15](------ [head]	[ 0] [ 1]---->[3rdcode, 2] [ 5](-----[ 3]--->[3rdcode_update1, 4] [ 6] | [ 7] | [10](-----[ 8]--->[3rdcode_update2, 9] [11] | [14](-----[12]--->[3rdcode_update3, 10] [15] [head]
Permanent development takes place on the main branch. At the time of version release the main branch is tagged, and a branch is created on the base of this tag. When bug fixing in release version takes place, it is performed on the "release" branch. Before issuing of a new release, fixes from the release branch are merged with the basic codes (to prevent repeating of the same errors). Then everything is repeated.	Permanent development takes place on the main branch. When it is necessary to perform long work, a part of developers goes to the "longwork1" branch. There they make modifications, which are merged with the main branch afterwards. The essence of this work is that it is sometimes necessary to modify, for instance, the system kernel. Moreover, the modifications have no effect on functions etc. Modifications are just special internal changes increasing efficiency and so on. The modification can be extensive enough to require work of several developers, or for one developer it may be better to checkin his work step-by-step to the server in order to secure the source codes.	This situation arises when you use ready source codes of other developers. The very first version of theirs is tagged '3rdcode'. Commonly it is necessary to adapt these codes some way: change titles, maybe add new functions etc. This work is performed on the main branch. Meanwhile the imported source codes can also be modified by their "owners". These modifications are added to the branch '3rdcode', and then are merged with the modifications on the main branch.
The project is developed. At the time of the project release the branch 'release1' is created. The project development is continued. At some moment it becomes necessary to fix bugs in the release version. Get the main branch again. Continue the project development. Point 4 can take place several times. A new release is ready. Merge modifications of the branch "release1" with the main branch. Create the branch "release2". ...	The project is developed. At the moment of taking a decision about long work Get the branch 'longwork1'. The branch "longwork1" is modified while others work with the main branch. At the end of work Merge modifications with the branch "longwork1". ...	The code of other developers is used. Right away the branch '3rdcode' is created. Adaptation on the main branch is performed. At the moment you get the new version from other developers '3rdcode_update1'. merge it with the branch '3rdcode'. Adaptation on the main branch is performed. At the moment you get the next new version from other developers create the tag '3rdcode_update2'. merge it with the branch '3rdcode'. Select modifications performed only between the tags '3rdcode_update1' and '3rdcode_update2'. Adaptation on the main branch is performed. ...

A tag is just a "snapshot" of a project in time. In Subversion each revision is a snapshot of the repository filesystem after each commit, and it can be used as a tag. But people often want to give some human-friendly names to tags, like release-1.0. Tag is a named snapshot, a symbolical connection with the specified revision of a project.

It is generally known that in SVN tags and branches realization is implemented by copying the source code tree to the repository. SVN uses so-called "cheap copies". Instead of making a real copy, the internal link will be created, pointing to a specific tree/revision. As a result branches and tags are very quick to create, and take up almost no extra space in the repository.

Actually there's no difference between tags and branches in Subversion. Both are just ordinary directories that are created by copying. The only reason a copied directory is a "tag" (or it is a "branch") is because humans have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a "branch". Generally, it's not recommended to commit any changes to a tag. If you need to make changes to a tagged release, create a new branch from the tag first and modify the branch.

You can create a new copy wherever you wish, but there are some standard, recommended ways to organize a repository. Usually a directory that holds the "main line" of development is called trunk, a directory that contains branch copies is called branches and a directory that contains tag copies is called tags.

When a repository holds only one project, the following layout is recommended:

/branches
/tags
/trunk

When a repository holds multiple projects, it's recommended to create such layout for each project:

/project1/branches
/project1/tags
/project1/trunk
/project2/branches
/project2/tags
/project2/trunk

You can work with tags and branches in an IDE. SVNSCC plug-in includes support for some basic operations, such as tag/branch merging. You can also use other SVN tools to perform any advanced operations, but keep in mind that plug-in automatically adjusts some auxiliary SVN properties and in this case you have to correct them manually.