Introduction to the directory structure of Android SVN development

SVN 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 of these methods

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.

The second method of

In each release of the branch to carry out their own development, trunk only to do 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. In 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
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

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 changes are likely to touch each other's changes.
The second development model (branching is the main development, decentralized):Advantages: Independent development, not easy to influence each other.
Cons: Complex management, the merge time is very troublesome, easy dead.
In fact, there is no fixed pattern, more time is used in combination of two modes.

Introduction to the directory structure of Android SVN development