Trunk,branches,tags usage details in SVN--management of project code

SVN has two modes in the project development process:

The first: Subversion has a very standard directory structure, which is the case. For example, if the project is PROJ,SVN address svn://proj/, then the standard SVN layout svn://proj/|+-trunk+-branches+-tags

This is a standard layout, trunk-based development directory, branches for the branch development directory, tags for Tag archive directory (not allowed to modify). But the specifics of how these directories should be used, SVN does not have a clear specification, more or the user's own habits.

There are two common ways to use these development catalogs. I am more from the point of view of software products (such as FreeBSD), because the Internet development model is completely different. 1. First method, use trunk as the main development directory
In general, all of our development is based on trunk development, when a version of/release development (development, testing, documentation, production installer, packaging, etc.) after the end of the code is frozen (artificially defined, can be managed by hooks). This should be based on the currently frozen code base, tag. When the next release/stage development task begins, the development of the trunk continues.
At this point, if you find some bugs in the previous released version (released version), or some very urgent feature requirements, and the version you are developing (developing version) does not meet the time requirements, you need to modify it on the previous version. The corresponding branch (branch) should be developed based on the corresponding tag of the release version.
For example, just released 1.0, is developing 2.0, at this point on the basis of 1.0 to make a bug fix.
According to the Order of time

1.0 development Complete, code freezes
Based on the trunk that has been frozen, play tag for release1.0
The directory structure at this time is
svn://proj/
+trunk/(Freeze)
+branches/
+tags/
+tag_release_1.0 (copy from trunk)
2.0 started development, trunk at this time is 2.0 of the development version
Found 1.0 bug, need to modify, based on the 1.0 tag do branch
The directory structure at this time 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, 2.0 development in trunk
After the completion of the 1.0 bugfix, Dev_1.0_bugfix based branch do release, etc.
Optionally, merge the Dev_1.0_bugfix branch back into the trunk (when this is done, depending on the 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, in each release of the branch to carry out their own development, trunk only for publishing use.
in this development model, trunk is not responsible for specific development tasks, a version/phase of the development task at the beginning, according to the release version of the new Development Branch, and based on the development of this branch. To give the example above, the timing relationship is:

1.0 development, do dev1.0 branch
The directory structure at this time
svn://proj/
+trunk/(not responsible for development tasks)
+branches/
+dev_1.0 (copy from trunk)
+tags/
1.0 Development Complete, merge dev1.0 to Trunk
The directory structure at this time
svn://proj/
+trunk/(merge from Branch dev_1.0)
+branches/
+dev_1.0 (End of development task, freeze)
+tags/
Do 1.0 tags according to the trunk.
The directory structure at this time
svn://proj/
+trunk/(merge from Branch dev_1.0)
+branches/
+dev_1.0 (End of development task, freeze)
+tags/
+tag_release_1.0 (copy from trunk)
1.0 develop, do dev2.0 branches
The directory structure at this time
svn://proj/
+trunk/
+branches/
+dev_1.0 (End of development task, freeze)
+dev_2.0 (for 2.0 development)
+tags/
+tag_release_1.0 (copy from trunk)
1.0 bug, fixed directly on dev1.0 branch

Personal recommendation, choose the second mode, trunk only do publish use, this is the most reasonable, in the development of branches, tag as post-release trunk code storage;

Trunk,branches,tags usage details in SVN--management of project code