Subversion has a pretty standard directory structure, something like this. For example, the project is proj and the svn address is svn://proj/, then 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 (modification is not allowed). However, svn does not have a clear specification on how to use these directories, and more is the user's own habits. For these development directories, there are two general usage methods. I am more from the point of view of software products (such as freebsd), because the development mode of the Internet is completely different. The first method, using trunk as the main development directory. In general, all our development is based on trunk development. When a version/release development comes to an end (development, testing, documentation, making installers, packaging, etc.), the code is in a frozen state (artificially stipulated, can pass hook to manage). At this point, it should be tagged based on the currently frozen codebase. Continue to develop in trunk when development tasks for the next version/phase begin. At this point, if it is found that the last released version (Released Version) has some bugs, or some urgent function requirements, and the developing version (Developing Version) cannot meet the time requirements, then it needs to be on the previous version. Modified. The corresponding branch should be developed based on the corresponding tag of the release. For example, 1.0 has just been released, and 2.0 is being developed. At this time, bug fixes should be made on the basis of 1.0. in chronological order
- 1.0 development is completed, the code is frozen
- Based on the frozen trunk,
the directory structure for tagging release 1.0 is
svn://proj/
+trunk/ (freeze)
+branches/
+tags/
+tag_release_1.0 (copy from trunk) - 2.0 began to develop, trunk is the development version of 2.0 at this time
- It is found that 1.0 has bugs and needs to be modified.
The directory structure of branch based on the 1.0 tag 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 1.0 bugfix is completed, the branch based on dev_1.0_bugfix will be released, etc.
- Selectively merge the dev_1.0_bugfix branch back to trunk as needed (when to perform this operation, it depends on the specific 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 is to carry out their own development in each release branch, and the trunk is only used for release. In this development mode, trunk does not undertake specific development tasks. At the beginning of a version/stage development task, a new development branch is created according to the released version, and development is based on this branch. Or take the above example, the timing relationship here is.
1.0 development, the directory structure of branch dev1.0 at this time
svn://proj/
+trunk/ (not responsible for development tasks)
+branches/
+dev_1.0 (copy from trunk)
+tags/- 1.0 development is 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/ - According to the 1.0 tag of 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 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 (2.0 development) +tags/ +tag_release_1 .0 (copy from trunk) - 1.0 has bugs, directly fix
the directory structure at this time on the branch of dev1.0
svn://proj/
+trunk/ +branches/ +dev_1.0 (1.0bugfix) +dev_2.0 (for 2.0 development) +tags/ +tag_release_1.0 (copy from trunk) - Optional code merge
This is actually a kind of decentralized development. When each part is relatively independent (functional), multiple dev branches can be opened for development, so that each person/group will not affect each other. Such as dev_2.0_search and dev_2.0_cache and so on. But this merge is a very painful thing.
It should be noted here that the sixth step of selective merge is to merge dev_1.0 (for bugfix) and dev_2.0 (for new version development) back to trunk when 2.0 development is over. Or merge dev_1.0 to dev_2.0 first, and then merge back to trunk after testing.
These two methods have their own advantages and disadvantages. The first method is to get a relatively pure development branch of dev_2.0, while the second method is more secure, because it needs to be tested.
The above are the two development modes I mentioned. There is no conclusion as to which one is better. Here's a general introduction to their respective advantages and disadvantages
. The first development mode (trunk for main development, centralized):
Advantages: simple management
Disadvantages: When there are more modules developed and more developers/small teams, it is easy to generate Conflicts affect each other's development. Because all changes may touch each other's changes.
The second development mode (branch for main development, decentralized):
Advantages: independent development, not easy to affect each other.
Disadvantages: complex management, very troublesome when merging, easy to die.
In fact, there is no certain rule here, and more often the two modes are used in combination.