Details on usage of trunk, branches, and tags in SVN

Subversion has a standard directory structure.

For example, if the project is proj and the svn address is SVN: // proj/, the standard SVN layout is

SVN: // proj/| +-trunk +-branches +-tags
This is a standard layout. trunk is the main development directory, branches is the branch Development Directory, and tags is the tag archive directory (cannot be modified ). However, SVN does not have a clear specification on how to use these directories, but it is still a habit of users.

There are two methods to use these development directories. I focus more on software products (such as FreeBSD), because the development model of the Internet is completely different. 1. The first method is to use trunk as the main development directory.
Generally, all of our development is based on trunk. When a version/release development ends (development, testing, documentation, installation program, packaging, etc, the code is frozen (as defined by humans, it can be managed through hooks ). Tag based on the currently frozen code library. When the development task of the next version/stage starts, development continues in trunk.
If you find bugs in the previous release version or urgent functional requirements, and the Development version being developed cannot meet the time requirements, in this case, you need to modify the previous version. The Branch should be developed based on the tag corresponding to the release version.
For example, if you have just released 1.0 and are developing 2.0, You must fix the bug on the basis of 1.0.
Chronological order

1.0 code frozen after development is completed
Tag release1.0 Based on frozen trunk
The directory structure is
SVN: // proj/
+ Trunk/(freeze)
+ Branches/
+ Tags/
+ Tag_release_1.0 (copy from trunk)
Development started in 2.0, and trunk is the development version of 2.0 at this time.
The bug 1.0 is found and needs to be modified. Branch is implemented based on the tag 1.0.
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 bugfix development in 1.0 bugfix branch and 2.0 development in trunk
After 1.0 bugfix is complete, perform release based on the branch of dev_1.0_bugfix.
Select the dev_1.0_bugfix branch merge back to trunk as needed (when to perform this operation according to the actual situation)
This is a very standard development model, and many companies adopt this model for development. Trunk is always the main development directory.

2. The second method is to develop each other in the branch of each release. trunk is only used for release.
In this development mode, trunk does not undertake specific development tasks. At the beginning of a development task of a version/stage, a new Development Branch is created based on the version already release, and develop based on this branch. In the preceding example, the time sequence is as follows:

1.0 develop and run branch of dev1.0
Directory structure
SVN: // proj/
+ Trunk/(not responsible for development tasks)
+ Branches/
+ Dev_1.0 (copy from trunk)
+ Tags/
1.0 Development completed, merge dev1.0 to trunk
Directory structure
SVN: // proj/
+ Trunk/(merge from Branch dev_1.0)
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Tags/
Tag 1.0 based on trunk
Directory structure
SVN: // proj/
+ Trunk/(merge from Branch dev_1.0)
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Tags/
+ Tag_release_1.0 (copy from trunk)
1.0 development, develop dev2.0 Branch
Directory structure
SVN: // proj/
+ Trunk/
+ Branches/
+ Dev_1.0 (development task ended, freeze)
+ Dev_2.0 (for 2.0 development)
+ Tags/
+ Tag_release_1.0 (copy from trunk)
1.0. Fixed bugs directly on the dev1.0 branch.

Original http://www.cnblogs.com/dafozhang/archive/2012/06/28/2567769.html