Using SVN development, directory Conventions and development processes

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 is

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.
The 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 will 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

2. 1.0 development Complete, code freezes

4. 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)
   

6. 2.0 started development, trunk at this time is 2.0 of the development version

8. 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)
   

10. 1.0 bugfix Development in 1.0 Bugfix Branch, 2.0 development in trunk

12. After the completion of the 1.0 bugfix, Dev_1.0_bugfix based branch do release, etc.

14. 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 are using this model for development. Trunk is always the main directory for development.

The second method, in each release of the branch to carry out their own development, trunk only for publishing use.

2. 1.0 development, do dev1.0 branch
   directory structure at this time
   svn://proj/
                 +trunk/  (no development Task)
                 +branches/
                               +dev_1.0 (copy from trunk)
                 +tags/
   

4. 1.0 Development completed, merge dev1.0 to trunk
   directory structure at this time
   svn://proj/
                 +trunk/  (merge from branch dev_1.0)
                 +branches/
                               +dev_1.0 (End of development task, Freeze)
                +tags/
   

6. Make 1.0 tag according to Trunk
   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)
   

8. 1.0 development, do dev2.0 branch
   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)
   

10. 1.0 bug, fixed directly on dev1.0 branch
    The directory structure at this time
    svn://proj/
    +trunk/
    +branches/
    +dev_1.0 (1.0bugfix)
    +dev_2.0 (for 2.0 development)
    +tags/
    +tag_release_1.0 (copy from trunk)
    

12. Selective Code Merge

This is actually a decentralized development, when the parts are relatively independent (functional), you can open multiple dev branches to develop, so that each person/group will not affect each other. such as Dev_2.0_search and Dev_2.0_cache. But this is a very painful thing to merge.

To note here, the sixth step of the selective merge, can be 2.0 after the development of the dev_1.0 (bugfix) and dev_2.0 (the new version of the development) merge back to the trunk. or merge the dev_1.0 into the dev_2.0 first, test it, and then merge back to the trunk.
Both methods have advantages and disadvantages, the first method is to get a relatively pure dev_2.0 development Branch, and the second method is more insurance, because to test it.

Above, is I say two development mode, specific which kind of good, and no conclusion. Here's a general look at their pros and cons
The first development model (trunk for main development, centralized):
Advantages: Simple Management
Disadvantage: When the development of more modules, the number of developers/small team more time, it is easy to create conflict and affect the other side of the development. Because all the changes are likely to touch each other's changes.
The second development mode (branch for main development, decentralized):
Advantages: Independent development, not easy to influence each other.
Cons: Complex management, the merge time is very troublesome, easy dead.

Using SVN development, directory Conventions and development processes