How to use functions such as tag, branch, and trunk in SVN

A long time ago, when I downloaded the source code and examples from the springsource website, I often saw directories such as trunk, branch, and tag. At that time, I didn't pay too much attention to the differences here. I often gave them my brains. Today we will talk about the differences and application scenarios of these things. In SVN, branch/tag is often confused in a function option.
In terms of implementation, branch and tag are implemented using copy for SVN, so their default permissions are no different from general directories. As for when to use tags and when to use branch, it is entirely subjective to choose based on specifications and needs, rather than mandatory (such as CVS ).
In general, tags are used to build a milestone. Whether it is release or not, they are all available versions. Here, it should be read-only. It is more of a display, giving a readable mark. Branch is used for parallel development. parallelism here refers to comparison with trunk. In this way, you will know that trunk is the main line project.
For example, if 3.0 is developed, a tag, tag_release_3_0 will be created at this time, and then the release will be implemented based on the tag, such as the installer. Trunk enters the development of 3.1, but 3.0 discovers a bug, so you need to create a branch based on tag_release_3_0, branch_bugfix_3_0, and perform bugfix based on this branch. When the bugfix ends, create a tag, marker, then, determine whether branch_bugfix_3_0 is incorporated into the trunk as needed.
Note that SVN is a global version. In fact, this is a tag, So we often see what release is based on the 2xxxx version of the XXX project. That's what it means. However, it also clearly gives the concept of a tag because it is more readable. After all, it is much easier to remember tag_release_1_0 than to remember a large version number.

One statement:
Branches: Branch
When many people work together, John suddenly has an idea that is not the same as the original design. It may be the addition of functions or the improvement of the log format. To sum up, this idea may take some time to complete. In this process, some operations of John may affect Sally's work. If John has a separate project from the existing state, however, it is not possible for Sally to correct the existing code in a timely manner. If Sally makes an independent attempt, it is also difficult for John to merge with the original one. In this case, the best practice is to use branches. John builds his branch and tests it in it. If necessary, he gets updates from Sally's trunk or collects his stage results into trunk.
(SVN copy sourceurl/trunk destinationurl/branchname-M "Creating a private branch of xxxx/trunk .")
Trunk: Trunk
The backbone is generally the main area of development,
Tag:
After a period of development, the project has reached a milestone stage. You may want to record the status of the code at this stage, so you need to tag the code.
(Svn cp file: // svnroot/mojavescripts/trunk file: // svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1-M "taged mirrorutils_rel_0_0_1 ")

It doesn't matter who is right or wrong.
Trunk: indicates the directory where the version is stored during development, that is, the code in the development stage is submitted to this directory.
Branches: indicates the directory where the released version is stored, that is, the stable version released when the project is released is stored in this directory.
Tags: the directory where tags are stored.
 
In this case, we need to explain the reasons for dividing the project into three directories. If the project is divided into Phase I, phase II, and phase III, the stable version of Phase I should copy the code to branches when phase I is completed. The code developed in phase II has no impact on the code of phase I, the newly added modules will not be deployed in the production environment. The stable version on branches is the Code released to the production environment. If a bug is found during use, you only need to modify the bug on branches, after modifying the bug, compile the latest code on branches and release it to the production environment. Tags is used to combine the code of the Bug modified on branches to trunk and create a version ID, after the bug code modified on branches is merged to the trunk, it is merged from the tags version to the latest version of branches to the trunk, so as to ensure that the bug code modified earlier will not be merged.

Requirement 1:
One customer wants to customize the product, but we do not want to modify the trunk code in the original SVN.
Method:
Use SVN to create a new branches, and use this Branche as a new starting point for development.
SVN copy SVN: // server/trunk SVN: // server/branches/EP-M "init EP"

Tip:
If you have no branches directory in SVN, you can use
SVN mkdir branches
New directory

Requirement 2:
Product development has been basically completed and passed strict tests. At this time, we want to release our 1.0 version to our customers.
SVN copy SVN: // server/trunk SVN: // server/tags/release-1.0-M "1.0 released"
What is the difference between this and branches?
Yes, branches and tags are the same. They are all directories, but we will not modify the release-1.0 tag and will not submit it any more. If yes, it will be branches.

Requirement 3:
One day, a fatal bug was suddenly found in the core of trunk, so all branches must be the same. What should I do?
Svn-R 148: 149 merge SVN: // server/trunk Branches/EP
148 and 149 are the version numbers modified twice.

Reprinted: http://wolfgangkiefer.blog.163.com/blog/static/8626550320111209363246/