What is the difference between a tag and a branch in SVN?

Question

This is from http://svnbook.red-bean.com/en/1.5/svn.branchmerge.tags.html

But wait a moment: isn't this tag creation procedure the same procedure we used to create a branch? Yes, in fact, it is. In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying. Just as with branches, the only reason a copied directory is a “tag” 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.

Technically, it's the same as a branch but conceptually we take it as a snapshot. In my svn repositories, I know that branches will include large features that may or may not have been merged into the trunk, but I use tags to mark release versions only.

The only difference is what you use them for, they are the same.

A branch is where you can develop work on a different version of the code to the main trunk.

A tag is a used to "tag" a release. Let's say I work only on the trunk. When I send V1 to a customer, I create a "V1 Tag" for it. Then I work on V2. When the customer has a problem with V1, I can just checkout the tag and begin debugging the issue on the exact same version as the customer. You can check into a tag, but you are not supposed to. If you need to do a V1.1 release, you create a branch from the same version as the V1 tag, and check in the fixes to that, and Tag it when it's released as V1.1.

"Trunk" and "Branches" are typically used for active and current development. It is where users commit/checkout files. It is usually where lots of activity happens.

On the other hand, "Tags" are typically used for creating a snapshot and milestone of your development. It is not really ideal for your team to make any commit/checkout on Tag folders.

Here are two examples of the applicability of Tags:

1. Branch archiving - When a Release or Feature branch has been finished or completely scrapped, you would usually delete the branch and this would effectively hide it from the HEAD revision. Some people don't usually delete these folders for archiving as they would prefer to see all their releases/projects. This though can cause the branch tree hard to navigate. That's why it is better to keep only the active and running project releases and features in the HEAD reivision of the branches folder. You can create a Tag copy of the last revision of those archived branches so that you can still see them on the HEAD revision. That way you can have quick snapshot of the last revision of the branch before the branch was archived and also keep things in the branches tree tidy.

2. Keeping milestones - Projects usually have many phases of development. Dev, UT, QA, pre-QA, post-QA, BAT, post-BAT, PROD, pre-PROD, post-PROD. You can use tags to make a snapshot of your development at every significant stage instead of relying on Revision numbers, Dates, or Comments.

Tags can be a big help on organizing things but can sometimes be chaotic too. It is important to have a standard naming convention for naming Tag folders.

Tags and branches are technically equivalent. The difference is how they are typically used.

You use branches to make an editable copy of code so that you can develop a stable and a working copy at the same time.

You use tags to make a read-only copy of code so that you can conveniently get that code later. Here's how this is used with daily builds. Each daily build just creates a tag with a name containing that build number. Once you need to get the sources of that long ago build later (for example, to reproduce a bug) you just export them from that tag.