Detailed explanation of the usage of trunk, branches and tags in SVN

Subversion has a pretty standard directory structure, something like this.
For example, the project is proj and the svn address is svn://proj/, then the standard svn layout is

svn://proj/|+-trunk+-branches+-tags
This is a standard layout, trunk is the main development directory, branches are Branch development directory, tags are the tag archive directory (modification is not allowed). However, svn does not have a clear specification on how to use these directories, and more is the user's own habits.

For these development directories, there are two general usage methods. I am more from the point of view of software products (such as freebsd), because the development mode of the Internet is completely different. 1. The first method is to use trunk as the main development directory.
Generally, all our development is based on trunk development. When a version/release development comes to an end (development, testing, documentation, making installers, packaging, etc.) ), the code is in a frozen state (manually stipulated, which can be managed through hooks). At this point, it should be tagged based on the currently frozen codebase. Continue to develop in trunk when development tasks for the next version/phase begin.
At this point, if you find that the last released version (Released Version) has some bugs, or some urgent function requirements, and the developing version (Developing Version) cannot meet the time requirements, then you need to update the previous version. Modified. The corresponding branch should be developed based on the corresponding tag of the release.
For example, 1.0 has just been released, and 2.0 is being developed. At this time, bug fixes should be made on the basis of 1.0.
The development of 1.0 is completed in the order of time

, the code freeze 
is based on the trunk that has been frozen, and
the directory structure at this time is
svn://proj/
+trunk/ (freeze)
+branches/
+tags/
+tag_release_1.0 (copy from trunk) 
2.0 starts to develop, trunk is the development version of 2.0 at this time and 
found that 1.0 has bugs and needs to be modified, based on the 1.0 tag to do branch
at this time The directory structure is
svn://proj/
+trunk/ ( dev 2.0 )
+branches/
+dev_1.0_bugfix (copy from tag/release_1.0)
+tags/
+release_1.0 (copy from trunk) 
1.0 in 1.0 bugfix branch For bugfix development, after trunk 2.0 development 
is completed, 1.0 bugfix is ​​completed, the branch based on dev_1.0_bugfix is ​​released, etc., and the branch dev_1.0_bugfix is 
​​selectively merged back to trunk as needed (when to perform this step, it depends on the specific situation) 
This is a very standard development model, and many companies use this model for development. trunk is always the main directory for development.

2. The second method is to carry out their own development in the branch of each release, and the trunk is only used for release.
In this development mode, trunk does not undertake specific development tasks. At the beginning of a version/stage development task, a new development branch is created according to the released version, and development is based on this branch. Or take the above example, the timing relationship here is:

1.0开发，做dev1.0的branch
此时的目录结构
svn://proj/
+trunk/ (不担负开发任务 )
+branches/
+dev_1.0 (copy from trunk)
+tags/ 
1.0开发完成，merge dev1.0到trunk
此时的目录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (开发任务结束，freeze)
+tags/ 
根据trunk做1.0的tag
此时的目录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
+dev_1.0 (开发任务结束，freeze)
+tags/
+tag_release_1.0 (copy from trunk) 
1.0开发，做dev2.0分支
此时的目录结构
svn://proj/
+trunk/ 
+branches/
+dev_1.0 (开发任务结束，freeze)
+dev_2.0 （进行2.0开发）
+tags/
+tag_release_1.0 (copy from trunk) 
1.0有bug，直接在dev1.0的分支上修复