Do the main development 1.0 development in the branch , and the directory structure
of the branch of dev1.0 at this time svn://proj/ +trunk/ (does not burden development tasks) +branches/ +dev_1.0 (copy from trunk) +tags/ 1.0 development is completed, the directory structure of merge dev1.0 to trunk at this time svn://proj/ +trunk/ (merge from branch dev_1.0) ===> test, tag or modify the merged bug, and responsible for the bug code Modify +branches/ +dev_1.0 (end of development task, freeze) +tags/ 1) After merging, if there is a bug in the test, you can modify the bug directly on the trunk, and tag it for release after the correction 2) After merging, there is no test The problem is directly tagged and released. After the release, it is found that there is a bug: it needs to be modified. Based on the 1.0 tag, make branch_buffix_1.0 . The directory structure at this time is svn://proj/ +trunk/
+branches/
+dev_1.0 (end development task, freeze)
+dev_2.0 (do 2.0 development)
+branch_buffix_1.0
+tags/
+tag_release_1.0 (copy from trunk) 1) If 2.0 development started, but not merged Into the trunk: After fixing the bug in branch_buffix_1.0, merge it into the trunk, and release it through the trunk tag. 2) If the development of 2.0 is completed and merged into the trunk: After fixing the bug in branch_buffix_1.0, it will still be merged into the trunk, but it will be merged into the trunk through the branch branch_buffix_1.0. tag release and so on! ! Summary: 1) No task code modification on the tag 2) New requirements development, branch from the trunk (the latest stable) and develop on the branch 3) After the development of the new requirement branch is completed or the branch bug is corrected, it must be merged into the trunk 4) The trunk can find problems after merging (without tagging) and make partial modifications. This is one of the methods, which is more suitable for website development with frequent changes and more bugs. The following is the description of the collected methods: The method of establishing Branch and tag in SVN is relatively simple. The operations in totoiseSVN are: 1. Select Branch and tag..
2. Fill in the URL in the ToURL in the interface that comes out, which is generally svn://IP/Project/branches/branch-1, so that a branch of branch-1 is created. Creating a tag is the same operation, but The URL is generally svn://IP/Project/tags/tag-1
3. The Createcopyfrom behind is used to choose which version of your current workingbase to create Branch and tag from. You can customize it according to your choice. Generally Select HeadRevision to create a
branch
svn copy svn://server/trunk svn://server/branches/ep -m "init ep"
>svn trunk, branch, tag
1. Branch and tag are implemented using copy for svn, So they are no different from general directories in terms of default permissions.
3. Introduce
trunk: the directory where the version is stored during development, that is, the code in the development phase is submitted to this directory.
branches: indicates the directory where the released version is stored, that is, the stable version released when the project goes online is stored in this directory.
tags: Indicates the directory where tags are stored.
3. Under normal circumstances,
tag is used to make a milestone, whether it is a release or not, it is an available version. Here, it should be read-only. More of a display, giving a readable markup.
Branch is used for parallel development. The parallel here refers to the comparison with trunk.
For example, when the development of 3.0 is completed, a tag, tag_release_3_0, should be made at this time, and then a release will be made based on this tag, such as an installer. Trunk entered the development of 3.1, but 3.0 found a bug, then you need to make a branch based on tag_release_3_0, branch_bugfix_3_0, and perform bugfix based on this branch, wait until the end of the bugfix, make a tag, tag_release_3_0_1, and then decide whether branch_bugfix_3_0 is merged into trunk as needed. trunk : Indicates the directory where the development version is stored, that is, the code in the development phase is submitted to this directory. branches : indicates the directory where the released version is stored, that is, the stable version released when the project goes online is stored in this directory. tags : Indicates the directory where tags are stored. Reprint SVN trunk branch tag Collection Subversion has a very standard directory structure, which is 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 are Branch development directory, tags are 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.
Generally, 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 be passed 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 you find 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 you need to update 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.
According to the order of time 1.0 is developed
and the code is frozen (copy from trunk) 2.0 starts 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 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 After the 1.0 bugfix is completed, release the branch based on dev_1.0_bugfix, etc. Selectively merge the dev_1.0_bugfix branch back to the trunk as needed (when to perform this operation, it depends on the specific situation) This is a very standard development mode , many companies use this model to develop. 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 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/ Make 1.0 tags according to trunk The directory structure at this time svn://proj/ +trunk/ (merge from branch dev_1.0) +branches/ +dev_1.0 ( The development task is over, freeze) +tags/ +tag_release_1.0 (copy from trunk) 1.0 development, do dev2.0 branch The 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 on the dev1.0 branch Fix Details how I applied SVN trunk, branches, and tags. This approach is also called "branch always", and the two are very close. Maybe what I have presented is not the best method, but it will give newbies some explanations about what trunks, branches and tags are and how to apply them. Of course, if there are some points in this article that need to be clarified/confirmed, or if there are some wrong points of view, please comment and express your own opinions freely. - A simple comparison of how SVN works is somewhat like a growing tree: * A tree with a trunk and many branches * Branches grow from the trunk, and thin branches grow from a relatively thick trunk Growing in * A tree can have only a trunk without branches (but this situation will not last long, as the tree grows, there will definitely be branches, ^^) * A tree without a trunk but with many branches looks like more like a bundle of branches on the floor
* If the trunk is diseased, the final branch will also be affected, and then the whole tree will die
* If the branch is diseased, you can cut it off and the other branches will grow!
*If the branch grows too fast, it can be very heavy for the trunk and eventually the whole tree will collapse
* When you feel your tree, trunk or branch looks beautiful, you can take a photo of it, That way you can remember how awesome it was back then.
- Trunk
Trunk is the main environment where stable code is placed, like a car factory that assembles finished car parts together.
The following will tell you how to use SVN trunk:
*
Never unless you have to deal with some bugs that are easy and quick to fix, or you have to add some extra logical files (like media files: images, videos, CSS, etc.) Develop directly on the trunk
*
Don't make big changes to the previous version for special needs, any related situation means you need to build a branch (as described below)
*
Don't submit something that might break the trunk, e.g. Merge from branch
*
If you accidentally break the trunk at some point, bring some cake the next day ("with great responsibilities come... huge cakes")
- Branches
A branch is an ordinary copy made from a subtree in an SVN repository. Usually it works like symlinks on UNIX systems, but once you modify some files in an SVN branch, and the modified files develop independently from the copied source files, you can't think so. When a branch is completed and considered stable enough, it must be merged back to where it was originally copied, that is: if it was copied from the trunk, it should go back to the trunk, or merge back into its original The parent branch of the copy.
The following will show you how to use SVN branches:
*
If you need to modify your application, or develop a new feature for it, create a new branch from the trunk and develop based on this new branch
*
unless Because a new subbranch must be created from a branch, otherwise the new branch must be created from the trunk
*
When you create a new branch, you should switch to it immediately. If you didn't, why did you create this branch in the first place?
--Tags
On the surface, SVN branches and SVN tags are no different, but conceptually, they have many differences. In fact, an SVN tag is the above-mentioned "take a picture of the tree": a named snapshot of a trunk or a branch revision.
The following will show you how to use SVN tags:
*
As a developer, never switch to, take out, or commit anything to an SVN tag: a tag is like some kind of "photo", not something real, tags Read only, not write.
*
In special or need special attention environment, such as: production environment (production), ? (staging), test environment (testing), etc., only checkout and update from a fixed (fixed) tag, never commit to a tag.
*
For the environments mentioned above, the following tags can be created: "production", "staging", "testing", etc. You can also name tags according to the software version, the maturity of the project: "1.0.3", "stable", "latest", etc.
*
When the trunk is stable and ready to be released, recreate the tags accordingly, and then update the relevant environment (production, staging, etc)
- workflow example
Suppose you have to add a feature to a project, and This project is under version control, you almost need to complete the following steps:
1.
Use SVN checkout or SVN switch to get a new working copy (branch) from the trunk of this project
2.
Use SVN to switch to the new branch
3.
Complete the development of the new feature (of course, do enough testing, including before starting coding)
4.
Once the feature is complete and stable (committed), and confirmed by your colleagues, switch to trunk
5.
Merge
your
branch into your working copy (trunk) and resolve a series of
conflicts )
8.
Submit the merged working copy to trunk
9.
If some deployments require a special environment (build environment, etc.), please update the relevant tag to the revision you just submitted to the trunk
10.
Use SVN update to deploy to the relevant environment
of the branch of dev1.0 at this time svn://proj/ +trunk/ (does not burden development tasks) +branches/ +dev_1.0 (copy from trunk) +tags/ 1.0 development is completed, the directory structure of merge dev1.0 to trunk at this time svn://proj/ +trunk/ (merge from branch dev_1.0) ===> test, tag or modify the merged bug, and responsible for the bug code Modify +branches/ +dev_1.0 (end of development task, freeze) +tags/ 1) After merging, if there is a bug in the test, you can modify the bug directly on the trunk, and tag it for release after the correction 2) After merging, there is no test The problem is directly tagged and released. After the release, it is found that there is a bug: it needs to be modified. Based on the 1.0 tag, make branch_buffix_1.0 . The directory structure at this time is svn://proj/ +trunk/
+branches/
+dev_1.0 (end development task, freeze)
+dev_2.0 (do 2.0 development)
+branch_buffix_1.0
+tags/
+tag_release_1.0 (copy from trunk) 1) If 2.0 development started, but not merged Into the trunk: After fixing the bug in branch_buffix_1.0, merge it into the trunk, and release it through the trunk tag. 2) If the development of 2.0 is completed and merged into the trunk: After fixing the bug in branch_buffix_1.0, it will still be merged into the trunk, but it will be merged into the trunk through the branch branch_buffix_1.0. tag release and so on! ! Summary: 1) No task code modification on the tag 2) New requirements development, branch from the trunk (the latest stable) and develop on the branch 3) After the development of the new requirement branch is completed or the branch bug is corrected, it must be merged into the trunk 4) The trunk can find problems after merging (without tagging) and make partial modifications. This is one of the methods, which is more suitable for website development with frequent changes and more bugs. The following is the description of the collected methods: The method of establishing Branch and tag in SVN is relatively simple. The operations in totoiseSVN are: 1. Select Branch and tag..
2. Fill in the URL in the ToURL in the interface that comes out, which is generally svn://IP/Project/branches/branch-1, so that a branch of branch-1 is created. Creating a tag is the same operation, but The URL is generally svn://IP/Project/tags/tag-1
3. The Createcopyfrom behind is used to choose which version of your current workingbase to create Branch and tag from. You can customize it according to your choice. Generally Select HeadRevision to create a
branch
svn copy svn://server/trunk svn://server/branches/ep -m "init ep"
>svn trunk, branch, tag
1. Branch and tag are implemented using copy for svn, So they are no different from general directories in terms of default permissions.
3. Introduce
trunk: the directory where the version is stored during development, that is, the code in the development phase is submitted to this directory.
branches: indicates the directory where the released version is stored, that is, the stable version released when the project goes online is stored in this directory.
tags: Indicates the directory where tags are stored.
3. Under normal circumstances,
tag is used to make a milestone, whether it is a release or not, it is an available version. Here, it should be read-only. More of a display, giving a readable markup.
Branch is used for parallel development. The parallel here refers to the comparison with trunk.
For example, when the development of 3.0 is completed, a tag, tag_release_3_0, should be made at this time, and then a release will be made based on this tag, such as an installer. Trunk entered the development of 3.1, but 3.0 found a bug, then you need to make a branch based on tag_release_3_0, branch_bugfix_3_0, and perform bugfix based on this branch, wait until the end of the bugfix, make a tag, tag_release_3_0_1, and then decide whether branch_bugfix_3_0 is merged into trunk as needed. trunk : Indicates the directory where the development version is stored, that is, the code in the development phase is submitted to this directory. branches : indicates the directory where the released version is stored, that is, the stable version released when the project goes online is stored in this directory. tags : Indicates the directory where tags are stored. Reprint SVN trunk branch tag Collection Subversion has a very standard directory structure, which is 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 are Branch development directory, tags are 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.
Generally, 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 be passed 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 you find 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 you need to update 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.
According to the order of time 1.0 is developed
and the code is frozen (copy from trunk) 2.0 starts 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 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 After the 1.0 bugfix is completed, release the branch based on dev_1.0_bugfix, etc. Selectively merge the dev_1.0_bugfix branch back to the trunk as needed (when to perform this operation, it depends on the specific situation) This is a very standard development mode , many companies use this model to develop. 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 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/ Make 1.0 tags according to trunk The directory structure at this time svn://proj/ +trunk/ (merge from branch dev_1.0) +branches/ +dev_1.0 ( The development task is over, freeze) +tags/ +tag_release_1.0 (copy from trunk) 1.0 development, do dev2.0 branch The 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 on the dev1.0 branch Fix Details how I applied SVN trunk, branches, and tags. This approach is also called "branch always", and the two are very close. Maybe what I have presented is not the best method, but it will give newbies some explanations about what trunks, branches and tags are and how to apply them. Of course, if there are some points in this article that need to be clarified/confirmed, or if there are some wrong points of view, please comment and express your own opinions freely. - A simple comparison of how SVN works is somewhat like a growing tree: * A tree with a trunk and many branches * Branches grow from the trunk, and thin branches grow from a relatively thick trunk Growing in * A tree can have only a trunk without branches (but this situation will not last long, as the tree grows, there will definitely be branches, ^^) * A tree without a trunk but with many branches looks like more like a bundle of branches on the floor
* If the trunk is diseased, the final branch will also be affected, and then the whole tree will die
* If the branch is diseased, you can cut it off and the other branches will grow!
*If the branch grows too fast, it can be very heavy for the trunk and eventually the whole tree will collapse
* When you feel your tree, trunk or branch looks beautiful, you can take a photo of it, That way you can remember how awesome it was back then.
- Trunk
Trunk is the main environment where stable code is placed, like a car factory that assembles finished car parts together.
The following will tell you how to use SVN trunk:
*
Never unless you have to deal with some bugs that are easy and quick to fix, or you have to add some extra logical files (like media files: images, videos, CSS, etc.) Develop directly on the trunk
*
Don't make big changes to the previous version for special needs, any related situation means you need to build a branch (as described below)
*
Don't submit something that might break the trunk, e.g. Merge from branch
*
If you accidentally break the trunk at some point, bring some cake the next day ("with great responsibilities come... huge cakes")
- Branches
A branch is an ordinary copy made from a subtree in an SVN repository. Usually it works like symlinks on UNIX systems, but once you modify some files in an SVN branch, and the modified files develop independently from the copied source files, you can't think so. When a branch is completed and considered stable enough, it must be merged back to where it was originally copied, that is: if it was copied from the trunk, it should go back to the trunk, or merge back into its original The parent branch of the copy.
The following will show you how to use SVN branches:
*
If you need to modify your application, or develop a new feature for it, create a new branch from the trunk and develop based on this new branch
*
unless Because a new subbranch must be created from a branch, otherwise the new branch must be created from the trunk
*
When you create a new branch, you should switch to it immediately. If you didn't, why did you create this branch in the first place?
--Tags
On the surface, SVN branches and SVN tags are no different, but conceptually, they have many differences. In fact, an SVN tag is the above-mentioned "take a picture of the tree": a named snapshot of a trunk or a branch revision.
The following will show you how to use SVN tags:
*
As a developer, never switch to, take out, or commit anything to an SVN tag: a tag is like some kind of "photo", not something real, tags Read only, not write.
*
In special or need special attention environment, such as: production environment (production), ? (staging), test environment (testing), etc., only checkout and update from a fixed (fixed) tag, never commit to a tag.
*
For the environments mentioned above, the following tags can be created: "production", "staging", "testing", etc. You can also name tags according to the software version, the maturity of the project: "1.0.3", "stable", "latest", etc.
*
When the trunk is stable and ready to be released, recreate the tags accordingly, and then update the relevant environment (production, staging, etc)
- workflow example
Suppose you have to add a feature to a project, and This project is under version control, you almost need to complete the following steps:
1.
Use SVN checkout or SVN switch to get a new working copy (branch) from the trunk of this project
2.
Use SVN to switch to the new branch
3.
Complete the development of the new feature (of course, do enough testing, including before starting coding)
4.
Once the feature is complete and stable (committed), and confirmed by your colleagues, switch to trunk
5.
Merge
your
branch into your working copy (trunk) and resolve a series of
conflicts )
8.
Submit the merged working copy to trunk
9.
If some deployments require a special environment (build environment, etc.), please update the relevant tag to the revision you just submitted to the trunk
10.
Use SVN update to deploy to the relevant environment