What is the difference between tag and branch in SVN?

Question

I have been working with SVN and TRUNK branches for many years, but never with TAG

Can someone advise what is the main difference between the two? What is the main purpose of labeling?

Answer 1

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

But wait a moment: isn't this tagging procedure the same procedure that we used to create a branch? Yes, actually. In Subversion, there is no difference between a tag and a branch. Both are just plain directories created by copying. As in the case of the branch, the only reason the copied directory is a “tag” is because people decided to treat it like this : while no one is ever fixed in the directory, it will always remain a snapshot. If people begin to do this, it becomes a branch.

Technically, this is the same as a branch, but conceptually we perceive it as a snapshot. In my svn repositories, I know that branches will include great features that may or may not have been merged into the trunk, but I use tags to indicate release versions.

Answer 2

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

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

The tag is used to "tag" the release. Say I only work on a chest. When I send V1 to a client, I create a "V1 tag" for it. Then I work on V2. When a client has a problem with V1, I can just check the tag and start debugging the problem in the same version as the client. You can check the tag, but you shouldn't . If you need to make a release of V1.1, you will create a branch with the same version as the V1 tag, and patch it and mark it when it is released as V1.1.

Answer 3

“Trunk” and “Branches” are usually used for active and ongoing development. This is where users commit / check files. This usually happens where there is a lot of activity.

Tags, on the other hand, are commonly used to create snapshot and development steps. It is not ideal for your team to make any commits / checks in tag folders.

Here are two examples of tag applicability:

• Archiving branches. When the Release or Feature branch is completed or completely canceled, you usually delete the branch, and this will actually hide it from the HEAD revision. Some people usually do not delete these folders for archiving, as they would rather see all their releases / projects. This can make tree branches difficult to move. Therefore, it is better to save only active and running releases and project functions in the HEAD section to restore the branch folder. You can create a copy of the tag for the latest revision of these archive branches so that you can still see them in the HEAD revision. Thus, you can get a quick snapshot of the last revision of the branch before the branch was archived, as well as save things in the branch tree neatly.

• Milestone Preservation - Projects usually have many development phases. Dev, UT, QA, pre-QA, post-QA, BAT, post-BAT, PROD, pre-PROD, post-PROD. You can use tags to take a picture of your development at every significant step, rather than relying on revision numbers, dates or comments.

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

Answer 4

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

You use branches to create an editable copy of the code to simultaneously create a stable and working copy.

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