Android SVN Developer's folder structure rendering

SVN has a very standard folder structure, which is.

For example, 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 folder, branches for the branch development folder, tags for Tag archive folder (do not agree to change). But the details of how these folders should be used, SVN does not understand the specification, many others are the user's own habits.
For these several development folders. There are two kinds of general usage. Many of my other things are from the point of view of software products (FreeBSD, for example), because the Internet development model is completely different.
The first of these methods

Use trunk as the Basic Development folder.

In general. All of our development is based on trunks. When a version number/release developed (development, test, documentation, production installer, packaging, etc.) after the end. The code is in a frozen state (artificially defined and can be managed by hooks). This should be based on the currently frozen code base, tag. The development of the next version number/stage continues to be developed in the trunk. At this point, assume that there are some bugs in the previous released version number (released version), or some very urgent feature requirements, and that the version number being developed (developing version) does not meet the time requirements, This will require a change on the previous version number.

The corresponding branch (branch) should be developed based on the corresponding tag of the distribution. For example, just released 1.0. is developing 2.0. In this case, a bug fix should be made on the basis of 1.0.

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 folder structure at this time is

svn://proj/+trunk/(freeze) +branches/+tags/    +tag_release_1.0 (copy from trunk)

2.0 started development. Trunk is now a 2.0 development version
1.0 bugs were found. Need to change, based on the 1.0 tag do branch
The folder 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, based on Dev_1.0_bugfix branch do release, etc.
According to the need to selectively dev_1.0_bugfix this branch of the merge back to the trunk (when to do this step, depending on the details)
This is a very standard development model. A lot of companies are using this model to develop. Trunk is always the main folder for development.

A different approach

Each release of the branch in the respective development. Trunk is only made public for use.

Such a development model where the trunk is not responsible for detailed development tasks, a version number/phase of the development task at the beginning of the time. The new development branch is based on the release number and is developed on this branch. Or the example above, the timing relationship is.

1.0 development, do dev1.0 branch
The folder structure at this time

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
The directory structure at this time

svn://proj/+trunk/(merge from branch dev_1.0) +branches/     +dev_1.0 (development task ends.) Freeze) +tags/

According to Trunk do 1.0 tag
The folder 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 developed. Do dev2.0 Branch
The folder 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
The folder 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

Selective Code Merge
This is, in fact, a decentralized development that, when the individual parts are relatively independent (functional), can open multiple dev branches for development. so that each person/group will not affect each other. Dev_2.0_search and Dev_2.0_cache, for example. But this is a very painful thing to merge.

Here's a little bit of attention. The sixth step of the selective merge is the ability to merge dev_1.0 (bugfix) and dev_2.0 (new version number development) into the trunk when the 2.0 development is finished.

or merge the dev_1.0 into the dev_2.0 first, then test and then merge back to the trunk.
Both approaches have pros and cons, and the first approach is to get a more pure dev_2.0 development Branch, while the other approach is more insured. Because you have to test it.
Above, is I say two development mode, detailed what kind of good, and have no conclusion. Here's a general look at their pros and cons.

The first development model (trunk for main development. Centralized): Strengths: Simple Management
Cons: When developing more modules, the number of developers/small teams is more. Very easy to create conflict and affect each other's development. All modifications are likely to touch each other's changes.
Another development model (branching main development, decentralized): Strengths: Each self-independent development, not easy interaction.
Cons: Complex management, the merge is troublesome time, easy to die.

In fact, rather than obvious here. Many other time combinations of two modes.

Android SVN Developer's folder structure rendering